News | Forum | People | FAQ | Links | Search | Register | Log in
Tyrutils-ericw V0.15.1
Hey, I got around to setting up a website for my branch of tyrutils: (complete with lots of screenshots of different settings of AO, sunlight, etc!)
and making an "official" release of it.

Nothing major changed compared with the last snapshot (may 1st), but a couple new things:

* .lux file support from Spike, for deluxemapping
* gamma control with -gamma flag and "_gamma" key
* rename -dirty flag to -dirt for consistency
* fence texture tracing is now opt-in only with the "-fence" flag.
* light should run a bit faster

This doesn't have lit2. Not sure what to do with that, tbh.

If there's a demand for it, I was thinking I could make a tool that upscales all textures in a wad by 2x or 4x, and adds a "-2x"/"-4x" suffix to the names. You could then manually get the higher-res lightmap on certain faces by applying the upscaled texture, and lowering the texture scale to 0.5 or 0.25 in your editor.

The only real disadvantage of this hacky method over lit2 is more face subdivision by qbsp. This isn't great, but it shouldn't be an issue if the hack is used sparingly (and bsp2 can be used if needed for higher face/vert limits.)

Anyway, enjoy, I hope this is pretty bug-free.
First | Previous | Next | Last
New Version V0.15.9 
Download here


- light: fix black fringes on bmodels that are touching against the world
- light: light passing through glass lights up the back side
- light: bmodels with "_alpha" < 1 and "_shadow" "1" set cast tinted shadows
- qbsp: support Quake 3 "Brush Primitives" .MAP format
- qbsp: save "_mincolor" for func_detail/group to the .texinfo file, now used by light
- qbsp: performance improvements

To elaborate on the "fix black fringes on bmodels" thing, v0.15.8 had a pretty severe bug where every func_door (or any bmodel) would have black edges wherever it touched the world, like an ugly/broken looking version of AO.

The reason I broke that in v0.15.8 was, I was trying to fix another bug, where bmodels (func_wall, etc.) that intersect the world, or have a face touching the world, would have broken lighting (usually all-black faces). Typical case where this would happen would be a large func_wall window that has a world brush slicing through it (or just touching the front).

So, that bug is back, because the "fix" I tried was much worse (black fringes on all bmodels). If you have a func_wall with black faces / broken lighting, the fix is to manually clip it against the world so it doesn't stick into the world anywhere. I'll see if I can come up with a better fix next version 
Fringe Of Darkness 
That's great to hear, I encountered the black fringe issue before and it is good to know it may be fixed on this release! 
Would it be possible to hit both bugs by having the compiler test if the bmodel intersects or not? Or would that require multiple passes or something like that? (Assuming extra passes would suck, which when it comes to speed they probably would :/) 
Performance improvements - intrigued, my latest maps have been bottlenecked by Qbsp which is wierd since vis always took the longest until recent improved versions. Curious what improvements you've made. 
@Qmaster - performance improvements are from undoing some mistakes I made when C++-izing bits of qbsp (unnecessary std::map lookups). Qbsp could be made a lot faster, though. e.g. Quake 2's is multithreaded.

Pritchard, I'm not sure if knowing if the bmodel intersected the world would help. I think I need to do something like: test whether each sample point is in the void or not, and just not use the ones that are in the void. 
Dumb Question 
How do you do lit liquids? I tried the commandline flags people are talking about here (-litturb etc.) and it just gives an error and doesn't run light. Was it removed or something? 
-splitturb option for qbsp.exe should do it; light.exe will automatically detect this and save lightmaps for the water. Looks like that option is missing from the docs.

Engine support is fairly rare (?) - I don't know what supports it, off hand. 
Engine support is fairly rare (?) - I don't know what supports it, off hand.

So I can "bake" lightmap on the water and it will be still fullbright in some engines, or what? 
So I can "bake" lightmap on the water and it will be still fullbright in some engines, or what?

Yes. There is that one software render engine that mankrip is doing that supports it I think. That's the only one I am aware of.

However, give other engine authors a slap and a tickle in the right place and I'm sure this feature can be adopted elsewhere (it bloomin well should be because it's coolbeans) 
I just checked my Jam 7 map to be sure I was remembering correctly, and Darkplaces supports lit water too, at least version 15:49:13 May 13 2014. Incidentally, I discovered the final version of my map is apparently broken in that engine for a different reason, which is just fantastic, but the lit water works as expected. It's easier to see the effect with r_wateralpha 1, of course. 
Crazy Idea 
All this talk of lightstyles in the AD thread got me thinking...

Say you had a moving object with start and end positions in radically different lighting conditions.

Imagine you could tell the light tool to light this object in position 1, assigning all light on it to lightstyle "x", and then light it again in position 2, assigning the light to style "y".

Then in the QuakeC you could fade lightstyles x and y in and out as the object moved.

Just an idea, but it struck me as interesting that this sort of cheap dynamic light effect boils down to being a compiler thing + a bit of QC.

You could even go nuts and leverage the fact you can have up to 4 lightstyles on the object, so can specify up to 4 different positions to light it in, allowing much more accuracy in the blending as the object moves around.

I may be missing a few "gotchas" but, does the theory sound basically correct? 
there are only 64 lightstyles total, and 32 of them are used by light.exe for switchable lights, the other 32 for "styled" lights (flickering/pulsing) -- of which about 11 are actually used in id1 progs. So I think this would work if you were willing to dedicate 2-4 styles just for that one moving object, and write a quakec modification as necessary to do the proper fading. 
It Is Intriguing 
I guess it would be something that could become an attractive idea when you have situations like in Hrimfaxi's rrp map, where there is a large section of a big room that moves up through several floors.

Wouldn't be worth it for run-of-the-mill platforms and what not, but for big setpiece movers I can see it having the potential to look quite sexy. 
There are 64 lightstyles, but Quake's BSP format only supports 4 different styles per surface.

IMHO, a more practical solution would be to use the "Lit BSP models" feature from the Makaqu engine 1.6 (used to adjust the brightness of the ammo boxes to the ambient lighting) and add an option to make it also work on internal BSP submodels. 
I only suggest the idea because it struck me as interesting that it doesn't need a custom engine.

I'd be happy to use up a handful of lightstyles on a moving room setpiece.

How is the "ambient lighting" determined in Makaqu? 
Cool Idea! 
I think the challenge is working out a standard between the mapper, light.exe, and the QC. light needs to have a copy of the logic for the func_door/train or whatever is moving. Func_door would be pretty easy, func_train would be trickier (unless the mapper marks which path_corner's to calculate lighting at, up to 4 per train?).

Also, things like making sunlight/sunlight2 use a lightstyle other than the default of 0 are certainly possible without too much work in the light tool. Easiest way might be for the mapper to specify a lightstyle number with a worldpawn key like "_sunlight_style" - light would then use that for the sunlight, and know not to assign that style number for a switchable light. 
I guess one implementation could be...

I would suggest light.exe should not need to know how the object moves - it only needs to know the positions to light it at - these could be specified in the map with "info_lightmodel" entities - they would mark the various positions (mins?) of the brushmodel. The info_lightmodel would target the brushmodel (to let light.exe know what to light, obviously), and also specify the "style" number to use. 
your sunlight suggestion is cool.

Question: what happens with bounce light coming off a surface with styled lights? Is there a bounce for each style? 
Mmm - yes the info_lightmodel sounds good.

Currently styled lights don't bounce at all, this was something I limited to make the first version of the code simpler, but I want to support it eventually. 
Yeah I guess bouncing styles would have a similar problem to styles on lights with 1/x or 1/x^2 falloffs: you could propagate styles to tons of surfaces everywhere and it could get out of control.

I think for most styled lights, you won't really notice the lack of bounce, but if you start doing styled sunlight, then I think sunlight bounce would be noticeable and you'd expect it to change like the direct sunlight does. 
How is the "ambient lighting" determined in Makaqu?

Nearly the same as in MDL models, using R_LightPoint and the entity origin, offset by the relative model position.

As for a pure QC + assets workaround... How about this:

- Make one model on origin A (start), and another on origin B (end).

- Set the B model to non-solid, and enlarge it by 1 unit (not 1%) on each direction.

- In the QC code, make the B model follow the origin of the A model.

- Implement code to fade the .alpha of the B model according to how far it is from the end position.

Almost every custom engine supports .alpha, so this shouldn't be a problem unless someone really wants to target vanilla WinQuake/GLQuake. 
Bmodels With _shadow 1 Lighting Problem 
Does light do simplified calculations on bmodels with _shadow 1? I get weird squares of shadows on solids from complex bmodels (in places, not everywhere). Splitting a big bmodel into a few smaller ones doesn't change anything. Any suggessions? 
There have been problems with _shadow 1 bmodels intersecting/touching each other, or the world. The faces that are touching can have artifacts, either black fringes or solid black or other artifacts.

I forget what the current status is, because I've been swapping in and out hacks to try to combat that.. but I'm working on a more correct fix.

Other than that, there shouldn't be any problem with shadows from bmodels. Check your version is 0.15.9, or feel free to email me screenshot/map if it seems like a different bug. 
If the bmodel doesn't touch another solid, the problem should be gone? 
Yeah, if they're not touching the problem should not occur (at least a 2 unit gap. The light sample points are 1 unit above the face, having these sample points blocked is what causes issues) 
that was very helpful 
does "-bounce 1" bounce lights with negative values? 
Negative lights are ignored by bounce 
Hexen 2 Rotating Entities Broken 
The use of an origin brush for rotating entities doesn't work with -hexen2. The origin brush is visible ingame and the brush still rotates around the map origin 
Yeah, there is no origin brush support at the moment.

Current behaviour is (designed for Q1 hipnotic rotation):
If a brush entity classname starts with "rotate_", qbsp looks at the "target" key, and searches for the targetted (point) entity. That point entity's origin becomes the origin of the brush entity.

I'm not sure if that is compatible with Hexen 2 rotation? 
Probably Not 
Hexen 2's is more like half-life, though it uses the "flags" key for how many degrees it should rotate. I think you can manually enter the origin to specify where it should rotate but that doesn't seem to work right in trenchbroom 
Figured Out A Sort Of Workaround 
You can actually manually put the origin in, but you have to place the brush at the map origin or it ends up outside the map.

Kind of a pain to light it properly but it works otherwise. 
lmao that sounds like an editing nightmare 
Tried implementing it, download available on the github issue

It might be handy for Quake too.
Hope I did it right.. if there is a brush in a brush entity with the "origin" texture, the center of that brush is used as the model origin (qbsp translates the model so that point is at 0 0 0, and sets the "origin" key).

Also light no longer cares about the classname starting with "rotate_", if the brush entity has an "origin" key set to something other than "0 0 0", the faces will be translated to that position during lighting (hopefully doesn't break anything?) 
Im Wondering 
Is there a standard for final compile settings? I assume people leave BSP and VIS parameters alone, except maybe -bsp2 for BSP? Is that something everyone uses, or only if the map somehow doesn't compile as a regular BSP? Is there any reason not to use BSP2?

For light, judging by the doc page on Eric's site, I'd guess people use -extra4, -gate 1, -bounce 1, and maybe some -soft? 
Final Compiles 
Yeah, the main thing is to use -extra4 on light; the other tools can stay with the default settings.

-gate 1 is probably fine but it's actually a faster/lower quality option than the default. -bounce 1 is something you want to use from the beginning if you are going to use it, since it'll change the entire look of the map. -soft is personal taste, it will make the final lightmap softer.

Is there any reason not to use BSP2?
It's best not to use the -bsp2 flag unless it's needed so the map will run on the widest range of engines (including vanilla ones). qbsp will print an error if the map exceeds limits so that it requires -bsp2. 
-bouncescale .8 or so? What about sunlight and dirt settings in the worldspawn? 
Tougher to generalize as those are more artistic choices. The screenshots / settings on the website give some starting points, you can also check map sources for ideas. 
I did check out some of the AD maps and was surprised to find very little dirt is used. Judging by the 1000 Cuts screenies I'd expect a lot more dirt, but maybe that's because of the greyscale. Sock seems to use 96 dirt, I'd think an intermediate between 256-512 would look nice. 
Sock seems to use 96 dirt, I'd think an intermediate between 256-512 would look nice.

Sock's 96 dirtdepth is not a bad value actually. A dirtdepth of 256-512 is something that works when looking at a distant shot of an otherwise fullbright map, like in the preview image on ericw's page. For a normally lit map, it means surfaces 256-512 units away will be darkening your target surface, which can just suck all the light out of interior rooms quite easily. 
I know it's probably a good value; Sock chose it. I have no Quake experience so all I have to go on are Eric's pics and various worldspawns. I need to jump in and make myself a test map. 
I prefer to set things like bounce in worldspawn and keep my compilation configuration as "universal" as possible. I just use -extra4 and -soft on my light config, and I usually use bsp2 for qbsp because what current engine doesn't support it, anyway? 
Don't use bsp2 if you don't need it. 
You can use the bounce parameters in the worldspawn? It doesn't say that on Eric's site. 
Yeah, i'm pretty sure. Also, because of otp, i'm only going to release my maps in bsp2 from now on. (Not that I release any maps...) 
Same. I only use in my compilation setup are the ones that can ONLY go in there. Otherwise the rest go in worldspawn.

Actually, speaking out loud, I need to add those to my .fgds. 
Derp. I Meant #668 
I have .fgd with all Tyrutils-ericw options for my JACK setup, should be easy to transfer to TB2 if you want. 
You can put this stuff in the fgd? How are you doing that? 
Open the .fgd with a text editor and add/edit worldspawn fields like you would with any other entity. 
You can use the bounce parameters in the worldspawn? It doesn't say that on Eric's site.

Good spot. Looks like the "Worldspawn Keys" section needs updating 
So Then 
Which fgd are you guys using? I have a quake.fgd that came with JACK and then the AD fgd. 
Dirty Choices 
I did check out some of the AD maps
Every mapper did their own thing and there are some who did not use detail brushwork or utilize lit files. Personally I compiled all my maps in AD with dirt parameters which are setup on the worldspawn so everyone can reproduce the results for themselves.

Sock seems to use 96 dirt
Its dangerous to take that parameter in isolation because the dirt AO system has several parameters which all play key roles in how the dirt is applied. You also need to remember the dirt parameters work with 2 other key systems, architecture and light entities!

I did countless tests with the new dirt AO system and found I wanted a strong dirt in corners that worked with finer brushwork detail. I also only added dirt to strong light source (excluded from all small/ambient light sources) and excluded it from most func bmodel entities.

There are many examples of different ways to setup lights and I would highly recommend anyone to look at Honey by CZG and The Hell that's coming by warrenm because both have source files included.

Honey uses strong point lights with many low fill (delay5) ambient lights and THTC uses many strong fill (delay5) lights for large windows and subtle fill lights for the rest. Both systems have different advantages and both create a different atmosphere. They are both pre dirt AO options, but they are useful for understanding lighting.

The final piece to the puzzle is architecture and in my AD maps I often have _dirt and _minlight parameters on bmodels and certain architecture to correct the overall dirt parameters I use. Its impossible to expect one global setting will fix all light issues and that is why I requested Eric add the ability to all map entities to switch lighting features on/off.

I also recommend everyone stop using the compiler for options and use the worldspawn instead! Why you might ask? Well so that everyone can learn from your source maps and try to understand how you did things.

I usually use bsp2 for qbsp
As I have said to Eric, this parameter should be on the worldspawn, it is really annoying to have to keep switching stuff around for different maps. The more parameters on worldspawn the better.

Which fgd are you guys using? I have a quake.fgd that came with JACK and then the AD fgd
Just edit/update either file with all the extra stuff you want. You can open a FGD in a text editor and cut and paste stuff around. Jack will run an error check on the file for you when it loads up a map, so its easy to spot errors. The format is not overly complex, the AD version should have plenty of examples of how to use the 'base' function and syntax formats for entity key types. 
Back To Front 
I also only added dirt to strong light source (excluded from all small/ambient light sources)
Sorry it is the other way around, I have not checked my parameters in a long time because I just use the same setup each new map.

Strong source lights = no dirt
Ambient source lights = AO dirt

The dirt is excluded from the strong light sources so that you get the hotness effect around lights. Remember Dirt AO will make every surface look darker and make strong lights sources feel dull.

Here is some more lighting tips to think about. 
I also recommend everyone stop using the compiler for options and use the worldspawn instead! Why you might ask? Well so that everyone can learn from your source maps and try to understand how you did things.

That's a really good point. 
Having as many compile settings as possible inside the map file makes it much more portable.

Imagine working on the map on different PCs (cheeky bit of lunchtime mapping at work anyone?) or on different editors, or after upgrading editors.

If as many settings as possible are properties of the map file, then it should reduce the time it takes you to sync up your settings across different environments.

That would be ideal anyway. 
It seems the only ones that ARENT worldspawn are things like -extra/-extra4, -lux, -onlyents... things that arent followed by some sort of value.

is it possible to convert these to be usable as worldspawn as well? 
Well... Not So Fast 
If the idea is that you find a good value and keep it for that map - no matter what sort of compile you are doing - then it's a property of the map and it should be a worldspawn value (sunlight, dirt blah blah)

If it's a setting that you keep changing to do different types of compiles (e.g. fast / final / onlyents /dirtydebug etc. ), then it's not a property of the map, and thus should remain as a commandline switch 
Do -extra and -extra4 gamma-correct when downsampling, or is that even relevant with lightmaps? It is something which makes a huge quality difference when generating mipmaps for diffuse textures. See for something of a discussion. 
Thanks Sock! 
I did countless tests with the new dirt AO system and found I wanted a strong dirt in corners that worked with finer brushwork detail. I also only added dirt to strong light source (excluded from all small/ambient light sources) and excluded it from most func bmodel entities.

I did notice several maps in the ones I've checked out that disable dirt on some bmodels, like func_doors. Why would you do that? Is it just because they move and their lighting changes enough that they look bad?

Just edit/update either file with all the extra stuff you want.

I know how to edit the FGDs, I just figured there would be a "standard" stock FGD that people use, like how everyone uses Eric's compile tools now.

Strong source lights = no dirt
Ambient source lights = AO dirt

So you sometimes apply different dirt setting per-light? I take it that's usually for indoor areas?

Honey uses strong point lights with many low fill (delay5) ambient lights and THTC uses many strong fill (delay5) lights for large windows and subtle fill lights for the rest. Both systems have different advantages and both create a different atmosphere. They are both pre dirt AO options, but they are useful for understanding lighting.

I come from Source multiplayer (TF2, CS) where almost all maps take place primarily outdoors, so we don't really use "phantom" fill lights much since the light_environment and indoor sourced lights take care of most of the playspace. 
Dirty Buggers 
Talking of dirt, I've always felt lights should have optional dirt "falloff" controls.

It struck me when playing around, that I'd want a bright light source to not apply dirt within a certain small radius, and then after this radius, ramp up until it's subject to the full dirt settings. Something like (on the light entity):


Should be self-explanatory, but if not:

From 0 to _dirt_off_radius units, no dirt.
From _dirt_off_radius to _dirt_on_radius, the dirt linearly ramps from 0 to full, and after _dirt_on_radius, it's full dirt.

What I currently do is use two lights in the same place: a bright light with dirt 1, and then a smaller light with dirt -1 so that it stops the immediate geometry around the light looking unrealistically dirty. The suggestion above means you can do basically the same thing but with just the one light entity. 
I'm still trying to visualize what the dirt actually looks like on point lights. It sounds like the light actually casts shadow at its outer reaches, but that doesn't make sense. I'm not at my PC or I'd make a little test. 
I'm still trying to visualize what the dirt actually looks like on point lights. It sounds like the light actually casts shadow at its outer reaches, but that doesn't make sense. I'm not at my PC or I'd make a little test.

Point lights don't "cast" dirt, so to speak. Imagine lighting a level with no dirt, then dirt is applied afterwards as a second pass. This dirt is applied over the existing light, so those lights are said to have "dirt on them".

For lights that have no dirt (dirt -1), I assume those lights are applied after the dirt pass, not before it, so the light can illuminate the dirty creases.

Caveat: the above is a guess, only ericw can confirm whether that's actually how it's done, but I'd be surprised if it's not the case. 
That makes more sense, thanks. 
ericw - is my assumption correct re: 3 passes (1: dirty lights, 2: dirt pass, 3: non-dirty lights)?

If so, where does bounce lighting fit into this? I assume bounce must be subject to dirt. 
@kinn + Sevin 
Yep, the 3 passes explanation is correct.

It's implemented slightly differently, but the result is the same: each light is rendered, possibly multiplied by the dirtmap (if dirt is enabled on that light), then summed.

Also, interesting idea about the dirt falloff. I don't think it'd be difficult to do.

I did notice several maps in the ones I've checked out that disable dirt on some bmodels, like func_doors. Why would you do that?

I'm guessing it's the same reason shadows look bad on doors; the shadow should be stationary when the door opens, but in Quake the shadow moves with the door texture. 
No, there's no gamma correct downsizing, that's something to try! 
I'm guessing it's the same reason shadows look bad on doors; the shadow should be stationary when the door opens, but in Quake the shadow moves with the door texture.

So it's just to lessen the effect? Disable the dirt so the moving shadow is less noticeable? 
Also, interesting idea about the dirt falloff. I don't think it'd be difficult to do.

For me, that would be really lovely as it would cleanly preserve the 1/x^2 falloff characteristics of my point lights, whilst also giving me precise distance control over when the dirt kicks in, as well as simplifying the whole setup. 
Isn't It About Time For A New Map Standard? 
I feel like the introduction of all these new features etc is being held back a huge amount. 
What new map spec do you have in mind? 
Something With Surface Flags For A Start 
From The Rumblings Around Here 
higher def light maps sound like they'd be useful 
Go Map For Q3 Or UE4 Or Whatever The Hell Then 
Higher res lightmaps have been talked about and we actually had an implementation at one point. Turns out they're one of those things that it's nice to talk about but when reality hits nobody really seems to want them. See the comment about "lit2" in the opening post of this thread, even.

This is something that came up a lot when I was doing the original BSP2 design. There is a degree of conflict between what people want and what's practical to implement. One of the overriding design goals of BSP2 was that it needed to be something that people would actually use. It needed to be quick and easy to implement and with a high degree of compatibility.

That's why it doesn't have all of the additional features that people might wish for. If you ask 10 different people you'll get 10 different answers, and any given 5 of those answers will probably be incompatible with the other 5.

So it doesn't have coloured light built-in, it doesn't have 32-bit textures, it doesn't have high-res lightmaps, it doesn't even change the .map format so you can continue using your favourite editor. Implementing it is just a handful of functions and structures and even software engines get to join the party.

That's why it's been successful where previous "let's design a new map format by committee" attempts have failed.

I think that I've a good idea of the kind of map/bsp format that people actually do want however, and I think it looks a little like Q2 BSP but with embedded textures, BSP2 extended limits and a Q3A lightgrid. 
Higher Res Lightmaps 
Yes, what mh said. See here for the start of a discussion on it when it was trialed:

Feedback was rather mixed.

I'm in the "meh" camp. It's funny how, once you start to increase the lightmap resolution, how quickly your thoughts seem to shift to "hmm looks a bit too crisp actually, how can I make this softer?" Heh. 
I'd be curious to know what Fifth is thinking about with surface flags. 
My experience is that people asking for a feature typically have a very specific problem right now that the feature they're asking for would solve.

For example: "can I have high-res lightmaps?" - meaning: "I'm shining a light through some grating and I'm not seeing the detail I'd like in the shadows".

Thing is, they can sometimes get so caught up in the specific problem they wish to solve that they forget about the knock-on effects of the feature they want.

So "can I have high-res lightmaps?" turns into "everything looks like crappy hard-edged Doom 3 shadows".

Fence textures were another example. I was asked could player movement be clipped by sprites, but it turned out that the problem was that sprites were being used for gratings/etc. Fence textures were an easy addition, everything works the way it should, and the end result is more generally useful.

There's more mileage in asking about what you wish to solve than there is in asking about how you wish to solve it. 
More Thoughts 
It's interesting reading my post on higher res light maps. I think I would still be interested in 2x detail (4x at a push) but it would have to be surface-dependent (specific areas only). I think when I did those tests I might have just done it on all surfaces (wasnt needed).

When I said surface flags that was certainly one example. Lots of features have been added to the compilers already that cover functions (_phong on groups, this is done by surface flags in Q2, same with alpha textures and scrolling surfaces). Maybe something that will allow terrain in the future and curved surfaces.

I dunno, I was just riffing ideas tbh. My next mapping projects will not be grandiose ones like with ad_tfuma so I am not in the market for new toys and gizmos just yet. 
I don't think it would look good if a 4x surface was beside a 1x surface. Unless you set things up very carefully there would be quite a jarring effect where the surfaces meet. 
One thing that I would like to see added is a way to project textures at full resolution. I wanted to do that with my noirjam map to get a smooth, natural transition between grass and dirt but was unable to due to the low resolution lightmaps.

I agree with the issues that high-resolution lightmaps raise, but better texture projection would be a nice feature to have. It would be a niche addition though, and like mh said, design by committee rarely works out... 
Sorry I can't get my head around why you'd want to fake texture blending via some kind of textured light projection.

Opening up photoshop and making some transition textures would be by far the best option.

If there was enough demand for proper texture blending, it would have to be an engine thing, perhaps done in a similar way to how Quake 3 does it. 
I got _dirt_on_radius / _dirt_off_radius up and running, if you want to check it out here is a snapshot.

For now the feature is only active if you set both keys, and there is no safety check that the _dirt_on_radius is larger than _dirt_off_radius.

This does seem like a cool feature.. here is an (ugly) screenshot with:

"_dirt_off_radius" "100"
"_dirt_on_radius" "500"

The light is in the upper left of the screenshot, and the dirt is only really visible on the back wall to the right 
@Kinn - Not Necessarily ... 
Blend it manually! tool screenshot results screenshot

I never knew I turned that into a tool, but a month ago I noticed someone talking about that tool.

I guess Spirit saved off a copy. 
Wow :) Thanks, that was fast! I've had a play with it and it makes a big difference - that will practically cut in half the number of lights I need. It looks great - torches in corners and alcoves now look correct, and the dirt nicely fades in as the light diminishes. A great addition imo :) 
I've never had much success with tools designed to blend textures; in general, my experience with working with .wad files has been pretty awful. So far the only hassle-free, bug free experience I have had has been with (our lord and saviour) ericw's defullbright tool, which actually does what it says on the tin without refusing to load half the formats it "supports" or failing to save changes properly...

Quake Texture Tool is nice, but in my experience it mangles the colours from time to time. I had to get some blended textures for my current map made by hand because everything QTT produced wouldn't match up when put next to either source texture.

In any case, projecting/blending textures is a much simpler, less painful experience that can easily be achieved with a map editor and the requisite format support. If it worked like it currently does, all you'd need to know is the names of the texture you want and how to set up a spotlight. No messing around with buggy tools from the 90s/early 2000s and no messing around with things like GIMP or Photoshop. 
@baker - looks useful!

@pritchard - sorry still not seeing it - leaving aside the issues associated with having an uber-high-res lightmap, you're still just projecting coloured light - it will just glow, like a stained glass window effect surely? 
Why would it glow? If you're projecting a texture, not a light, you're not projecting coloured light. Perhaps that's how it works now?

To be honest I just miss being able to paint textures in Cube 2. As far as I know that was done through some kind of "map" of the level, but I don't know the specifics of how it worked. But if you're familiar with that, that's the sort of functionality I'd like to have. Probably a pipe dream... 
In any case, projecting/blending textures is a much simpler, less painful experience that can easily be achieved with a map editor and the requisite format support. If it worked like it currently does, all you'd need to know is the names of the texture you want and how to set up a spotlight. No messing around with buggy tools from the 90s/early 2000s and no messing around with things like GIMP or Photoshop.

What are you smoking? 
Why would it glow? If you're projecting a texture, not a light, you're not projecting coloured light. Perhaps that's how it works now?

When you project a texture with a spotlight, you are adding positive light to the lightmap. Let's say you project a green grass texture onto some gravel - all that will happen is you are adding some greenish light to the gravel texture - you'll see the gravel texture brightened up a bit and tinted green 
You can project a texture and set up any blend func you wish. Do it before lighting, do it after lighting, whatever.

Just because it's commonly used for spotlights doesn't mean it can only be used for spotlights.

So project a green grass texture onto gravel and set up the blend as GL_ZERO, GL_SRC_COLOR and you get a straightup modulation of grass and gravel. Set it up as GL_ONE, GL_ONE and you add grass to gravel. Set it up as GL_ONE, GL_ONE_MINUS_SRC_ALPHA and set up the alpha channel of the grass texture and you get a masked overlay - kinda like Quake's sky. 
All my comments are assuming we're just using the existing system but with just a higher-res lightmap. 
EricW, Baker, Spike And Other Engine Devs 
So it seems obvious to me that the people who work most on the engines should drive any changes they want to see / would see to be beneficial to the community. So Baker / EricW / Spike... What would you want to see in any future map format?

Regarding the screenshots from the upscaled lightmap experiment.

The jaggies were gone, which was nice... But the sharp shadow edges were a bit much. It seems that some quantity of blending is nice. 
The "jaggies" disappear in regular resolution lightmaps when you compile light with -extra4. 
Lately I've been learning lots of simple shit that I should already know.

Thanks OTP. 
Any changes you make to the map format are useless if noone ever uses them
until them we have bspx, to embed optional stuff that noone else even realises is there. 
So, leading off of my post in the Mark V thread, is there any particular issue with these compiler settings that might cause lit water not to work? 
Aha, should be "-splitturb" without the "s"..
qbsp should be printing an error about unknown option I think? 
-onlyents And Strings 
Really obscure, odd thing that had me stumped for quite a while! Posting in this thread because it seems to be something to do with the compile.

AD mod - create a misc_textbook and just put (for example) "\\bTest Message\\b\\n\\n" in the "message" field, and "\\bTest Message 2\\b" in the "message2" field (without quotes).

If you do an -onlyents compile, the \\b gold lettering breaks and you see the backslash character in the text. If you do a normal compile, then the gold lettering appears properly. Does this happen to anyone else or is it just me? 
This board treats backslashes different when you preview a post versus actually posting.

In my above post, please ignore the double-backslashes.

They are supposed to be single-backslashes (so in my example above I am actually typing single-backslash-b etc. in the message field in the quake editor.

How confusing is that! 
Try doing an onlyents light compile (after the qbsp -onlyents); I think that'll fix it.

the \b handling is in done in light.exe for some reason; it probably should be moved to qbsp. 
That did the trick :) 
Strange Lighting Some of my func_detail gets really dark in the middle and has obvious seams with the nearby brushes. Here's how it looks in the editor:

Any ideas? I can mask the effect by adding another nearby light but the seam is still visible. Changing the geometry works to fix it as well, which is what I've chosen to do. 
Hmm, it's tough to say. It could be a few things:
- try a light compile with "-phongdebug" and set "r_lightmap 1" in engine.
- try adding "-novisapprox" to light. This disables some light culling that can be over-aggressive and can cause artifacts like this, although it shouldn't be messing up in this case. 
I'd also say your geometry is overly complex on the floor. You're more likely to get lighting errors and such when the detail is so high. I'd also say high detail on the floor is not always desirable because of Quakes quirky physics. 
In my experience with the floor so far it's has worked out well, but I could easily change from func_detail to func_illusionary and use flat clip brushes for movement if it becomes a problem.

I'll try your suggestions soon Eric. 
I Wouldnt Do That Tbh 
as you may encounter similar lighting issues etc. Just keep it clean and simple, Quake doesnt need to be super high poly :) 
I like me some polygons, dangit! I'm well aware of the func_illusionary lighting problems, but they all have workarounds and should be minimal in the first place considering my minimal amount of brush overlap. 
Was fence texture raytracing ever re-added? It'd be nice to have, my current map uses such textures quite a bit. 
It's in v0.15.9. It should work automatically (the old version needed a -fence command line flag, which is no longer needed) 
Is it supposed to be reported in this line if it is acting?
Embree_TraceInit: 0 skyfaces 40734 solidfaces 0 fencefaces 0 selfshadowfaces 0 skipwindings

I'm noticing that there are no "fencefaces" reported, which makes me wonder if it is actually working. 
Yeah, it should list >0 "fencefaces" there.
Check that "_shadow" "1" is set on the entity (assuming the fence texture is used in a func_?) 
Now that more people are trying to implement lit liquids, and Darkplaces already supports it, can you turn -splitturb on by default in the BSP compiler?

It has literally zero negative side effects, and the impact on performance caused by the subdivision should be negligible in any engine nowadays.

It's nice that the compiler is already capable of compiling lit liquids, but no one is using this option yet. All of those new maps being released in the last months could have looked a lot better with lit liquids. 
I'd like to see this happen too.

I think there are still a few decisions to be shaken out regarding lit water, but we're not going to get a useful discussion until a sufficient number of people have had a chance to see what it actually does look like, what all the weird corner cases are, and how it interacts with existing content. 
I'm not sure about enabling -splitturb in these tools by default; I don't want to push it on mappers retroactively, which is what would happen if people upgrade tools and don't test their maps in DarkPlaces. In the longer run I think it'll be a feature like skyboxes (or phong shading, bounce lighting, etc) where mappers might use it if they're going for a modern look, and not use it if they're going for a retro look.

But I agree the community in general needs to see this in action to evaluate it; DarkPlaces isn't that useful for evaluating the look because the water surfaces doesn't do the swirl effect. I have only seen it in DP and it looks OK but tends to make water look a bit like a solid wall.. I think the warping will help counteract this (as well as careful setup of wateralpha / minlight on the water brushes, from the mapper). We need a Fitzquake style engine with it. I meant to make a patch to Quakespasm for it some time, at least for making test builds to post here. 
Does Darkplaces have a cvar to disable it? If a map doesn't look good with it, the user can disable the effect.

It's about having options. If lit water isn't compiled into the map, the users have no option. 
DarkPlaces [...] doesn't do the swirl effect. [...] tends to make water look a bit like a solid wall.. I think the warping will help counteract this

Exactly. In Retroquad it looks great because the texture swirls while the lighting doesn't. 
Yeah, I compiled e1m2 with lit water and noticed the "solid wall" effect too, but this was even with the turbulent effect.

Another thing I noticed is that the lightmapping tends to make translucent water less noticeable; it's actually more difficult to fine-tune a good value of r_wateralpha that works well.

The thing about fullbright translucent water surfaces is that they actually blend with the lighting on the solid surfaces below them. This comes back to the statement I made earlier on about translucent surfaces probably not needing to be lit at all, but yeah, it's something that people are only ever going to be able to evaluate once they see it.

Having a cvar to enable/disable options is useless IMO if the cvar isn't exposed to the player somehow. Because most players won't even be aware that it exists. That's a total cop-out; people don't read readmes so you need to pick sensible defaults and unfortunately I suspect that while community judgement on lit water is going to be "it looks crap", people are so drunk on the kool-aid that we're going to end up with a set of defaults that in a years time nobody will want. 
To me the value of lit water is that even if it is a tradeoff of sorts and can have undesirable effects (I still haven't really managed to see it in action aside from screenshots, so I can't say if it makes water look like a solid surface or not), it's still better than having water that glows in the dark.

That's really what it's about for me - letting mappers use water in dark areas without it looking awful and out of place. The way it is right now looks fine in places like this, but not so much in places like this. You can make it more subtle by increasing wateralpha (it's 0.6 in these screenshots), but then you lose some of that murkiness and uncertainty from the water that a mapper might want. And it doesn't solve the problem completely anyway.

By the way @ericw, thanks for the hint about the _shadow key, worked a charm. Too bad my fence textures are too finely detailed and barely let any light through :( 
mh: Having a cvar to enable/disable options is useless IMO if the cvar isn't exposed to the player somehow.

That's why I'm used to implementing menu options for this kind of thing. And such menu options needs cvars.

Lots of engines have options to toggle colored lighting, wateralpha and so on. It's really hard to believe you haven't thought of this possibility.

Anyway, even if nobody else implements it in their engines, even if nobody else compiles it in their maps, I'll just keep doing my own thing. Even if everybody else thinks it looks bad. 
I think Retroquad looks great but i also think it should be a criminal offense that I can't play it ;-; 
Clip Brushes Question 
Let's say I have a lot of fiddly little clip brushes used to smooth over some terrain (turning the collision into steps basically, not slopes). Should the clip brushes be made func_detail, like the terrain, or should clip always be world / func_group, regardless of how detailed it is? 
I Don't Know About Quake 
But in Source clip brushes don't cut visibility. 
I used to place small brushes in func_wall, but for vising sake it would be func_detail. 
Clip Brushes 
I'm pretty sure it's fine to put them in func_detail, they will behave the same as if they are in worldspawn or func_group.

(Clip brushes are only included in hull1/2, and func_detail is specific to hull0, so the features shouldn't have any interaction) 
Thanks very much, that all makes sense. 
3 Questions 
1) If I want to upgrade to the latest tyrutils-ericw (v0.15.9) on Linux 64 bit, can I just download the archive, extract it and immediately use it? That's what I tried, and qbsp seems to work ok, but light gives me the error message
error while loading shared libraries: cannot open shared object file: No such file or directory.
There is a file called "" in "tyrutils-ericw-v0.15.9-Linux/bin/", though, so I'm confused.

2) When using running light, does it matter in which order I type in the command-line options? E.g. is there a difference between
light -bounce -extra4 -dirt
light -dirt -bounce -extra4?
Are they both correct? Or both wrong? Do I need to give "bounce" a value? (I've tried various variations, but I find it hard to know when/if I'm doing things correctly, as I'm not sure what the in-game results are supposed to be).

3) This is not a huge problem (yet), but one brush face in a map I've been working on suddenly stopped being lit, both when running light normally and with "-dirtdebug" (which should light all faces evenly, right? That's what it's always done before when I used it). Is there a known reason for this kind of thing? Is there anything one can do to avoid it, or is it one of those mysterious things that just sometimes happens?

This is using tyrutils-ericw 0.15.8 and an outdated version of TB2 beta (the reason being that when I last tried to upgrade TB2, I seemingly had to first upgrade my then freshly installed OS, or fiddle around with repository settings to get the necessary dependencies updated to the versions required for updating TB2 -- and I didn't have the time or patience to do so. At some point I will update both). I just mention this in case this might be an issue related to the editor rather than the light tool (in which case I'll just have to live with it until I update my OS and editor). Oh, and my engine is QuakeSpasm 0.92.0. 
1. Looks like I messed up packaging the linux binary.
If you don't mind running light manually from the terminal, try "cd"-ing into the "bin" directory and run:
LD_LIBRARY_PATH=$(pwd) ./light {options here}
Otherwise, I'll fix it in the next release.

2. Order doesn't matter, except the map has to come last. There is no parameter for -bounce (there are separate flags like -bouncescale X though). Only a few commands take optional parameters (-soft can take a number like "-soft 2"). The tool should be strict if there are mistakes in the command line options, and refuse to run. For now the manual is the best reference: here, or the website front page.

3. It would just be a bug in "light". Things that have caused black faces in the past:
- bmodels (func_wall, etc.) that intersect the world
- regular world faces with an obstruction near the center of the face, within 1 unit of the surface.
I *think* I fixed all of these for the next version, I should put up a beta or release soon. Feel free to send me your map/bsp if you want me to check it out though. 
Thank You Very Much For The Response, Ericw 
1. I didn't know there was an alternative to running it manually from terminal; that's what I always do. :) Anyway, I tested typing that arcane string of characters and it works, thanks! That'll tide me over till the next release.

2. Order doesn't matter
Thanks for clearing that up! :)

There is no parameter for -bounce
the manual is the best reference
I had already read through the manual and the stuff on the front page a few times, but was still a little confused.

The example of the front page is
-bounce -bouncescale 2
which made me think that it doesn't take any parameters.

But the manual made it seem to me as if do need to specify a value ("n"):

bounce n

Enables 1 bounce, 0=disable even if set in worldspawn. Available as a worldspawn key.

I guess I'm misinterpreting something?

3. Thanks for all of this info. The brush with the unlit face is just a regular unobstructed worldbrush, but it's good to know these things for future reference.

Thank you very much for offering to look at the map. If the problem persists, I might take you up on the offer, but a lot is bound to change in the map, so the problem might resolve itself in the mean time. Plus, the file is a huge mess of provisional brushwork, newbie mistakes, textures that have not been properly aligned yet, etc., and though I know no-one but me cares, I'm still too embarrassed to share it in its current state. 
Intensity Of Color Lights 
I noticed that color lights have different intensity than the neutral ones. In the picture all the lights have the "light" key of 150, but the attenuation and the intensity is very different.
If that's "a feature", what can I do to make them look more uniform? 
That looks like a custom engine screw-up. What engine are you using? 
When you change the color, it reduces the intensity of the colors that you don't want. If a white light has RGB color of 1, 1, 1 and you make it pure blue, the color becomes 0, 0, 1.

You could reduce the brightness 1/2 by making the color 0.5, 0.5, 0.5

I don't think the light program compensates for this and maybe it's what you are seeing. 
That's not the problem at all here. Look at the image - that's an engine thing. The light program just can't blow the lightmap brightness up like that. 
Okay, you're probably right. The picture was so dark I couldn't really see anything other than the white and blue blobs, and I was too lazy to turn the gamma up. 
White and colored lights shouldn't have vastly different intensity / falloff, and if anything white will be brighter than colored as Rick was saying.. so something is wrong here.

Is the "_color" key set on the white lights (the dim ones on the right)?

The engine's brightness/contrast controls are blowing out the colors so it's hard to tell what's going on. Also assuming that is Darkplaces, you can view the lightmap only by entering "gl_lightmaps 1" in the console. 
It's clearly amplifying the light instead of reducing.

Somehow, it seems to be adding the color to the light instead of multiplying. 
Ericw's Right 
It's Darkplaces. Only the color lights have "_color" key. I'm at work right now but AFAIR I didn't use any "_deviance".

If anyone wants to check it, I could take more screenshots with higher brightness or should I mess with any other parameters?

I'll check the same settings in FitzQuake and will let you know. 
Use floats, ie values between 0 and 1.
Values greater than 1 will either oversaturate or be divided by 255, depending on implementation (welcome to the wild west).

The lighting in that screenshot actually has nothing to do with tyrlight[-ericw], because the engine you're using is basically ignoring its output and making up its own thing based on the map entities.
set r_shadow_realtime_world 0 to get it to behave properly. This'll also boost framerates significantly, so a double win...

ericw, how about a feature to ignore/strip certain lights so you can more easily set up rtlights without damaging static lights? maybe 
Ah Yes, Darkplaces 
Loathe as I am to suggest continually adding fudges to support all the different implementations custom engines expect - on the compile side, would it make sense to always normalise 0-255 values into 0-1 values when saved to the bsp? 
Fgd File Updated 
I've updated my FGD file for version v0.15.9 of Ericw tools so you can now set phong on brush models and projected textures on lights.

Tested with J.A.C.K steam release 
Thanks Daz! 
Spike, ah, rtlights explains it. Hmm maybe a key to omit an entity from the bsp could be handy, although in this case the mapper could just use colors values in 0-1.

I kind of hate to add hacks like scaling the "_color" values in the bsp to 0-1, although I suppose it improves compatibility with darkplaces "auto-rtlights" and should be pretty safe. 
Floats Do It! 
Thank you Spike! As soon as I changed the values into floats, the light got rendered nicely.

Also, when I turned off rtworld, as suggested by EricW, the rendering was pretty close to how FitzQuake does it. Although, I do have to admit it, it's a bit bland this way.

If anyone wanted to check a poor presentation of the above, go to 
Face->numpoints > MAXEDGES (64) 
Got this error when working on my map, after I made a brush that was way too finely curved for its own good. Is there any solution other than just having rough edges? :( 
Csg Split it into several smaller brushes? 
More than 64 verts will crash most Quake engines, since engines also contain code that assumes that the max verts in a face is 64. Example:

So you definitely want to keep the tools error and correct your brush instead. 
Can't the BSP compiler split such brushes automatically? 
New beta:

Has the .map conversion feature in qbsp, so you can do:
qbsp.exe -convert valve
and it will write out a copy of the map in Valve 220 format to It can also convert to "quake", "quake2", "bp" (quake 3 brush primitives).

I labelled it "beta" because it's not tested enough, light has a large change to how sample points are positioned. (so unexpected black faces should never happen any more, e.g. this
My God 
so unexpected black faces should never happen any more  
at least one of the causes is gone. 
I think you may have added in a cause:

Also, would it be possible to turn off the bouncing for styled lights with an option? It's causing a lot of "too many lightstyles" warnings on my map.

In more positive news, converting my map seems to have gone off without a hitch! :D 
So it's the black artifacts around the floor tiles? Was that shot with -extra4? I should be able to reproduce it.

re: bounce, good point, it should be opt-in, I guess. "_bounce_styled" "1" worldspawn key?

Thanks for testing and glad the .map conversion worked! It should be pretty trouble free because all the brush planes are passed through losslessly. 
No, no -extra4 or soft. I haven't been using those parameters as I test the map. If you like I can create a github issue with the .map and perhaps a compiled .bsp/.lit? I did just try splitting off the problem area into its own map but I couldn't even reproduce the exact lighting I have... 
Sure, or just emailing me the .bsp + .lit is fine too. I was just trying to reproduce it now. 
Also, interesting tidbit but nothing of any real issue: Converting the map to valve format through your tools seems to have reversed the order keys are listed in for TB2. Classnames are now at the bottom rather than the top. Not the case for newly created entities of course. 
thanks for noticing that, should be harmless but I'll fix it! 
Can sunlight be assigned a lightstyle? Thinking it could be cool to fade it in/out via QC. 
Not Atm 
It's really easy to add though, i'll add it after fixing Pritchard's issue. 
Can sunlight be assigned a lightstyle?

Man that could open up some interesting visuals. 
It's really easy to add though, i'll add it after fixing Pritchard's issue.

Cool! Sounds like a good addition

Man that could open up some interesting visuals.

Random dipping of light from clouds in an overcast sky...the strange pulsing of an alien sun...a simplistic day/night cycle (obvs no moving shadows but whatevs, it's not as if you can animate the skybox)...

You could sync up the light variation with some variation in the fog and skyfog settings to sell the effect better.

I did think it might be interesting if it was possible to have multiple different sunlight setups, all on a unique lightstyle (well you'd be limited to 3 I think) - morning, midday, evening - and you lerped their light intensities in QC (along with "night", but that wouldn't be a lightstyle, just an absence of light). But that's probably overkill and the shadows might still look odd.

I'm not really sure what the performance implications are with massive amounts of lightstyled surfaces though. Are there any these days? 
I just looked up how lightstyles work, is there any limit to the length of the string? Or could you actually have a light that took a really long time to complete it's cycle? That would be a lot of letters...

Also seriously? It's done with letters of the alphabet??? 
Yeah, you can set up those strings and have the light cycle automatically, or you can just set a single brightness value explicitly (e.g. say you wanted a slow day/night cycle thingy, I guess you'd want to set up a slow think function and increment the brightness in the think) 
Uhm, how come this QBSP generates a whooping 11k more clipnodes than other compilers on my map?! 
Hmm, I don't remember touching anything related to clipnodes since this forked from tyrutils.

I just tried compiling and it looks like I can reproduce that:

bjptools_xt_290914_phong2: 38011 clipnodes
tyrutils-ericw_0.15.10_beta1: 44953 clipnodes

So it's producing 18% more clipnodes than bjptools_xt. Is that the same kind of percent increase you're seeing / what are the total numbers of clipnodes? 
Around 41% in my case if my math is correct.

bjptools_xt 1.2.5: 27174 clipnodes
tyrultils_ericw 0.15.9: 38372 clipnodes

(Also roughly 700 more marksurfaces with tyrultils) 
Fun Fact 
Hmap2 produces an even higher count: 43601

So it's settled then: Bengt Jardrebb ftw! 
I don't mind using the old txqbsp_xt in order to not exceed the standard marksurfaces limit, but I'd like to use this light.

I was wondering if the problem of light not passing through sky had been fixed. 
Negke thanks for the info, I'll look into optimizing the clipnodes sometime.

Rick: sometimes this qbsp will produce fewer marksurfaces, so try both.

About making ordinary lights go through sky faces, I tried it a while ago and I don't think it's worth the code complexity, and it caused a significant slowdown.

If I added a way to add entities to specify multiple suns would that help? Alternatively just make a hollow box connecting to the window, it should only add 1 extra leaf and a few sky faces. 
Tried latest beta and I receive too many light styles on faces when I didn't on the latest stable version. Going to assume that's with styles now bouncing?

A few notable black faces I was keeping track of are still showing as pure black. Just reporting! 
latest build from here has a bug.
Rotate_object arent lit, leaves them all black. 
i'll look into it. The git master and 0.15.10-beta1 versions of light are half-baked at the moment, I recommend the stable version 0.15.9. 
Light Absorption For Deep Liquids 
When a deep lake full of mud or slime is in a very bright area, the lighting from the outside will illuminate it as if the liquid didn't exist. This is specially true for lakes under open skies with sunlight.

How complicated would it be to implement an option in the light tool for underwater faces to receive gradually less light according to their distance from the water surface?

I suppose it could work this way:
1) If the face is underwater, check if the light entity is not underwater;
2) If the light entity is not underwater, make a list of all liquid surfaces between it and the underwater surface;
3) For each ray, check which liquid surface in its path is closest to the light entity;
4) Calculate the distance from the liquid surface to the underwater face, and use it to reduce the brightness received by the lightmap.

Note: Light entities placed underwater shouldn't be affected by this, because their underwater brightness was deliberately set by the map author.

I think this feature could be very useful, specially in areas with both water and slime - the slime would look more muddy than the water, because the bottom of it would be harder to see.

Maybe this could be implemented through an entity field in func_detail liquid brushes. 
But lava glows on its own. So does slime, doesn't it? 
I don't think slime necessary glows or doesn't glow, though it depends on what kind of slime it's supposed to be...

In Lava's case, you'd never realistically be able to see underneath the "surface" so no one can say if it glows or not :P

I feel like this effect could already be possible with negative lights - those subtract from the lightmap right? You could place a bunch of them underwater and it'd probably be possible to have the desired effect. 
Light Entitys With Negative Values? 
Never knew they exist... 
I've never tried using them myself but it's in the docs. 
I was thinking of Quake 2 where (all?) liquid textures had surface light. So I guess that's actually irrelevant.

Quake's palette shifting effect tends to make underwater areas too bright anyway but negative light would probably still help. 
Attenuate faster if the trace crosses a water surface.

How do you see this working with moving liquid bmodels? 
How do you see this working with moving liquid bmodels?

Let's follow the current standard:
"_shadow" "n"
If n is 1, this model will cast shadows on other models and itself (i.e. "_shadow" implies "_shadowself"). Note that this doesn�t magically give Quake dynamic lighting powers, so the shadows will not move if the model moves. Default 0.

Liquid faces from inline bmodel entities should only be taken in consideration if their entity's self._shadow is 1.

Shadows are, essentially, instant attenuation. Faster attenuation can be considered semi-related to shadows. 
The volumetric water attenuation is certainly do-able; the raytracer is already set up to have side effects when a ray hits certain surfaces.

The latest stable release from last fall has "stained glass" support, i.e. if you make bmodel with "_shadow" "1" and "_alpha" "0.5", light rays going through the entity will be partly attenuated and pick up the color of the texture.

So a simplified version of water attenuation would be not considering the distance traveled underwater, but just attenuate the ray when it goes through the surface. But on the other hand, I can imagine it would look cool to have bright sunlight at the water surface fading to black (thinking of an e1m4 type environment).

Anyway it's a cool idea to add to the todo list. My first priority now is fixing the breakage that Pritchard reported a while back, which I'm making good progress on but kind of a bit drained on tbh. 
"Bit Drained On..." 
That's fine, just know that what you are doing is really really great! There is no going back to the old tools now.

Incidentally, is your light or qbsp multithreaded? I know vis is, which changed light to be my current bottleneck (bounce fun notwithstanding). 
Thanks, appreciate it :)

Light is multithreaded, qbsp is not. Qbsp could get a lot faster, it spends most of its time in CSGFaces checking if each brush intersects each other brush in the map. Quake 2's qbsp is multhreaded.

The main performance tip for light is to avoid using -extra or -extra4 except on your final compile, and also add -gate 0.1 or something to reduce the overhead of delay 2 lights. 

No problem, I can wait. 
Light Diff 
When a map is recompiled, compare its entities with the entities in its previously compiled BSP file, and use the radius of each light to determine which surfaces had their lighting changed.

This way, when recompiling lights, the light tool can simply copy all unchanged lightmaps from the BSP file, and compile only the modified lightmaps rather than recompiling all lightmaps.

Bounce lighting can make this complicated, so I'm not sure if it would be possible. 
I feel like if you're testing within each light's radius to see what brushes have changed, you're already doing a lot of the grunt work for compiling a new lightmap...

It could work for a rough and messy sketch if you were willing to let a lot of edge cases slip through and accept the odd corrupted face or two, but then you invite the possibility of someone releasing a map compiled with that option turned on... 
testing within each light's radius

Only for the light entities that changed. Quite often, it will be only 1 light. 
What I've been thinking of, that's sort of related to that, is making a light preview tool; it would be a small GUI application with a 3d view with WASD+mouselook. You would open a map file and the tool does qbsp and light and displays the result, except the light baking is done on faces near the camera first, and the 3d view updates as each face finishes baking. Then it would refresh whenever the .map file is re-saved. I think this would be pretty sweet. 
yeah, what I have always wanted is a tool that lets me edit the lighting in realtime. I think that a diff-based approach to recalculating lightmaps would be fast enough to make this possible. Most edits would only affect one light, which has only local effects. Of course editing the sun values would not be as easily optimized. 
I'm not really sure what happens if you use old light data on a new BSP, but wouldn't it be pretty broken if you edited the brushwork around a light that hadn't changed. Say you made a ceiling, put a light on it, ran qbsp/light, then built the rest of the room and tried to patch.

I don't know what that would look like but I imagine it'd be quite bad... 
Yeah, that would be quite broken.

There are also complexities around light styles, combining lights with the same style, and packing in new lightdata/updating light offsets, which may in theory require to recalc for the entire BSP. 
Question: Does ._phong work across multiple entities when combined with ._shadow, to make multiple func_wall, func_illusionary, etc blend smoothly with the world's func_detail "entities"?

Right now I'm on mobile and can't test it. 
Pretty certain it does mankrip 
Iirc, separate func_detail / group will be blended if the _phong settings allow it. But other bmodels never blend with each other or world. 
The Cursed Words... 
Having a real time lighting renderer like ericw would be really neat. If you were able to cull light calculations to the player's view (You'd have to be very generous - bouncing their view around corners to find lights that should cast but would otherwise be missed), you could potentially have an engine that displayed in the traditional quake style, while keeping the main benefits of lighting in real time like moving lights.

I can already imagine a whole set of horrendous edge cases arising from this sort of thing, but it'd be a pretty neat thing to see and something that I'd hope modern computers would have the power to pull off... 
I have ZERO issue in paying for a light preview tool to be created. Even if its separate from TB. 
Mapper's Most Wanted List 
�WYSIWYG Editor (lighting, models, anims, particles, the works)
�Leak indicator light: red dot on status bar means leak, green means you're good, updates in realtime during editing. (Plus toggleable prt lines, yes this is same concept as lighting preview)
�Auto entity naming and quick linking/pathing (JACK is pretty good actually)

In earnest, having a simple little window with a 3D fly view and a button click to "render", even if it took about 20sec, would be an awesome help to have over on my 3rd monitor.

sleepwalkr might be able to integrate something into Trenchbroom's 3d view if you mocked it up.

Go for it ericw! Would make adding all the nifty features easier, such as testing phong or bouncescales. 
Yeah, I've just tested, and it doesn't work:

The back of the column is a func_detail with _phong 1. The front of the column is a func_wall with _phong 1 and _world 1.

If _phong 1 worked on mixed entity types with _world 1, we could work around some of the BSP's planar/vertex accuracy limitations by alternating between func_detail and func_wall brushes. This would make the engine clip their planes at the rendering level, which is completely accurate and doesn't produce distortions. 
#821 @mankrip 
quake's lighting logic has some bias on its dotproducts that increses the amount of light on surfaces that are nearly perpendicular to lights (which is important for lights placed near said surface).
You can disable the effect with _anglescale 1 (I think it is now - vanilla hardcoded it to 0.5)

the '_phong' key simply calculates surface normals on a per-sample basis instead of per-surface (thus meaning its misnamed as it doesn't change the lighting formula). It affects the lighting, but not the shadows. While it would be possible to push the sample worldspace positions according to the same calculated normals, and determining shadows based upon those, such things would be quite unreliable in practice - for instance, a concave surface curve would logically push those sample positions inside the surface, which would result in all traces being obscured with the surface shadowing itself.

so yeah, that's why you get sudden lighting changes on the edge of pillars - because -anglescale is biasing the light on one side while the other side is in pure shadow.

if you want to try it anyway, this is the maths I use in FTE for tessellation:
vec3 w = p0*bary[0]+p1*bary[1]+p2*bary[2];
vec3 t0 = w - dot(w-p0,n0)*n0;
vec3 t1 = w - dot(w-p1,n1)*n1;
vec3 t2 = w - dot(w-p2,n2)*n2;
w = w*(1.0-factor) + factor*(bary[0]*t0+bary[1]*t1+bary[2]*t2);
you should be able to shove something like that into GLM_InterpolateNormal (and convert from glsl to cpp - I already renamed stuff from glsl). You'll then need to return the smoothed position back through multiple callers to the point where its copied into the lightmap samples array.
Bonus points if you can calculate the barycentric coords (read: interpolation weights) for general polygons instead of just triangles.
like I say, you'll need to clamp the shadow-point to never be behind the surface to avoid the more obvious glitches. once implemented properly you'll get smoother lighting around corners (although due to the nature of traceline shadows, it'll probably still be somewhat sudden without anglescale 1). 
@mankrip, smoothing between separate models is too difficult to attempt, imho, because smoothing relies on the model having been processed by QBSP. i.e. it involves walking around the mesh (exploring neighbouring faces to a vertex, and neighbouring faces to a face, etc.). If the models weren't clipped against each other, the smoothing wouldn't work.

@spike in current git, I wiped out the "traceline to position sample points" thing. Instead I'm trying to use the same code as phong shading, so exploring the mesh by following connections between faces. So in a concave surface, it should work properly and give world space positions that are consistent with the interpolated normals.

Only problem is, it needs some more work.. Pritchard's case in #773 was failing because of t-junctions in the bsp. I want light to work properly if qbsp didn't add t-junc vertices, so I'm making light do it (in memory only).

re: GLM_InterpolateNormal, apologies for the current mess I made in the code and weird names.. I tried using the glm library a bit, then decided I didn't like it. (100 layers of indirection/ abstraction for basic vector operations, slow as hell debug builds,..)

On the plus side the test suite is growing slowly. 
Is there an automated way to import the configuration from the non-Steam version?

I've just bought JACK on Steam, and upon launch it didn't detect that the non-Steam version was already installed. 
Dumb Me! 
Wrong thread. Wrong tab.

Anyway, thanks for the explanations, ericw and Spike. I'm already going to implement something which should serve as a partial workaround, but I'll keep this info in mind for future research. 
Quake's dotproduct is a simple dot(L,N) * 0.5 + 0.5; i.e a rescaling from -1..1 to 0..1 (excluding the spotlight cutoff for simplicity):

angle = DotProduct (incoming, l->facenormal);
angle = (1.0-scalecos) + scalecos*angle;

But scalecos is 0.5 (, so substituting:
angle = (1.0-0.5) + 0.5*angle;

And evaluate (1.0-0.5):
angle = 0.5 + 0.5*angle; 
Fence Volumes 
Is it possible to make brushes with fence textures be compiled in a similar way to brushes with liquid textures?

By that, I mean making them become properly see-through. Currently, any brush with fence textures will clip any polygons from other brushes that touches them, which results in open holes where the other brushes should be visible.

The only difference to liquid textures is that the pointcontents of fence brushes would have to be set either to solid or to empty. I guess the first case would give problems to the renderer, and the second case would give problems to the physics, but from the top of my head I'm not sure. 
I'm not sure how much interest there would be in changing how fence textures are compiled as it's already quite easy to resolve the "clipping" by making brushes using fence textures be a func_ brush such as illusionary or wall. 
Lighting Artifacts 
Pic. What's going on there? Any way to get rid of this without anglesensing the shadows from the spikes away? 
Apparently it's related to the increased texture scale (2.5-3x). Jury-rebbed BJP light doesn't seem to have a problem with it (but it lacks several feature I require). 
Make sure to use v0.15.9, the .10-beta1 turned out to be broken.

If that's not the problem, I'm not sure from the screenshot, could I have a look at the .map (just for what's in the screenshot would be fine)? 
There's a specific problem I'm having with it, when BSP entities partially inside of walls gets darker edges because part of their surfaces is in pure darkness.

If such entities were part of the world, their surfaces would be clipped by the compiler and there wouldn't be any parts of them in pure darkness. But to be part of the world, they would have to be compiled similarly to liquid volumes, without clipping other brushes.

Currently I can work around this by making the other brushes that touches them into func_wall entities too, but IMO this isn't the most efficient approach. 
the renderer doesn't care if something's solid or not, just that its a leaf or node.
same with physics, really.
just make sure those fence-solid leafs don't get merged in to leaf 0 like all other solids, and that vis considers them transparent despite solid (can't say I've really looked into the vis tool itself, maybe it already goes by leaf 0 instead). 
Thanks for the explanation. The BSP tree architecture is something I've not started studying deeply yet. 
Devil In The Detail 
I also came across an issue with detail brushes. Not sure if it's a bug or simply a technical restriction and downside of the way detail brushes are done in Quake, and also not sure if it's a general thing or only applies to certain special cases.

I had a compact bit of architecure flush to the wall of a building and turned it into func_detail in order to use phong shading on it. The building's wall behind it remained solid world geometry. As it turns out, having the detail brush touch the wall like it did caused the compiler to disregard visblocking for the wall which resulted a situation where a large part of the interior was being rendered despite being completely out of view, causing wpoly to increase by 1500. Making the func_detail 'flatter' by including only the front part of the detail architecture didn't change anything; it seemed to be entirely related to the touching of detail and world brushes on that particular part of the wall.

Now, this might be an edge case caused or faciliated by the shape and construction of that particular area (sloped brushes, same brushes for inside/outside etc), but still a potential risk to keep in mind, especially if remaining unnoticed until the final release of a map.

If anything, this is meant to raise awareness that excessive func_detailing can be detrimental, too. Perhaps the code can be tweaked to make sure this can't happen, or maybe it something to live with due to the hacky nature of it. 
Some screenshots to clarify.

The face is the func_detail in question. The wall below is a door, but instead of only rendering the corridor behind it (hell knight), it even draws the atrium way out sight, much of its upper and lower parts. 
isn't a catch-all.

I have found in a number of my maps that I get a speed gain in compile times but not always ideal results in culling in the game. 
That Face... 
Is so Tron. 
Tyricutils Func_detail 
Good lighting and faster vis time and same, worse PVS splitting.

Source engine func_detail: Good lighting, faster vis time, and clean PVS since it treats them as func_walls.

Thing is, I don't know how you would gain the benefits of true func_details (the Source way, the right way) unless the compiler turned them into info_notnulls or func_walls. Otherwise, the mod would need to support func_detail entity in its progs.dat


Unless engine support for func_details was added. Currently the compiler de-entity-ifies them into normal brushes. But if they were kept... 
What you describe about detail brushes in the Source engine sounds close to my suggestion about see-through solid volumes. 
Isn't all VIS/PVS data precompiled in quake? Why do we need to turn brushes into a specific kind of entity in order to get a desired effect?

Would it not be possible for VIS to just look at a func_detail, say "I'm going to treat this as if it were a func_wall" and be done with it?
How does it work currently? 
Yeah, I'm going to take another stab at fixing func_detail's PVS issues. mankrip your suggestion sounds good to me, and it sounds like it'll share the same implementation.

How about (assuming I can get these to work :-)

- func_detail_fence - same as "func_detail" but doesn't clip away world faces, so it's usable for fence textures. Like func_wall, but doesn't use up an entity.
- func_detail_illusionary - same as func_detail_fence but no collision hulls. Like func_illusionary, but doesn't use up an entity, and as a downside it would block gunfire. Not sure if this would be useful? 
That's good.

func_detail_illusionary would actually be really useful to simulate crouching. The real ground would be lower, with a func_detail_illusionary ground a little above. Of course, this would affect monsters too, so its usage may be limited to small areas. 
I don't care much about quicker VIS times; all I want to achieve is phong shading and occasinally minlighting on brushes without taking up additional entity/model slots. Although marksurfaces eventually forced me to turn many of them into func_wall after all.

As for the issue I mentioned above, there's a workaround. As it turns out, phong and minlight also work on func_group, so making the big face a group instead of detail gets all the effects without the PVS problems. Good to know, albeit even more hax... 
Is there a way of increasing the lightmap resolution? 
Use A Bigger Texture Than Scale It Down 
texture scale is linked to the lightmap resolution. 
LIT2 (see the opening post) supports increased lightmap resolution and we all went round the block with it a few years ago. No clear community consensus formed.

My own opinion is that it's a poor trade off for hugely increased file sizes, and it doesn't even look as good as you'd think owing to losing the soft edges on shadows. 
It could be useful to add a compiler/worldspawn option to set portal brush contents to CONTENTS_EMPTY, because as it is, using CONTENTS_WATER, portals can't be (partially) placed inside of slime and lava. 
By the way, Quake's episode 4 already has maps with underwater portals. So, allowing portals under slime and lava would bring more feature consistency to mappers. 
Azure Agony 
Used black for its teleport texture.

I think you mean teleport. Portal is something created by vis.

That's not a terrible idea but I think it would serve better as an entity field: _overridecontents 1 or something to that effect. 
Just copy the teleport texture and call one copy *lavateleport and the other one *slimeteleport in your wad file. 
thats brilliant. 
New Stuff 

I've been working on qbsp, and did a rewrite of func_detail to fix the vis problem. The big change is, func_detail no longer seals the map (which makes more sense anyway IMHO). No more of this! (baker's shot of a way-too-big-PVS from some spot in ad_mountain).

Also, I added a bunch of func_detail variants (illusionary, wall, fence) described in more detail on the release page. Thanks for the suggestions, mankrip, and Spike a while ago.

This is still bleeding edge so it's marked as a beta, and I still haven't fixed the light issue you reported Pritchard. 
I didn't think that had ever cut vis. I know it doesn't in GoldSrc/Source. Was func_detail something third-party FGDs added to Quake? 
Yeah it was something added later to the Quake tools - afaik originating in Quest.

It's not that func_detail blocked vis, but certain setups would cause bogus portals (what negke is reporting in #835) resulting in bogus vis results. 
light: styled lights no longer bounce by default, set "_bouncestyled" "1" to enable.

Just want to confirm this means bounce is disabled on id's lightstyles "flicker, pulse" etc.?

Is that set in worldspawn or on the light entity or both? 
Yep, it's for flicker/pulse and also lights that start off and are switched on. The "_bouncestyled" key is on worldspawn and affects all the flickering / switchable lights in the map.

(The first release I did with bounce lighting didn't support having those lights bounce; now they can, but it's opt-in.) 
great. thanks for all your hard work on these tools. 
thanks for -forceprt1 - I was always editing prt file in text editor to load it to JACK :P 
thanks for -forceprt1 - I was always editing prt file in text editor to load it to JACK :P 
Why Is The Win32 Download 
about half the size of the Linux and Win64 versions? 
32 Is Half Of 64 
Oh, Ummm, Haha, Yeah... 
I'm still running a 32-bit system, I didn't realize that doubling the bits would also double file sizes. Makes sense. 
would it increase compiling time if i added "_phong_ to my "func_detail" entry in FGD and thereby all my func_detail? 
would it increase compiling time if i added "_phong_ to my "func_detail" entry in FGD and thereby all my func_detail? 
If "_phong" "1" is set on every func_detail there will be a little overhead, maybe 10% slower, but nothing major.

The main thing I would watch for is unwanted smoothing. The default _phong_angle is 89 which might be a bit high (face normals up to 89 degrees apart will get smoothed together). Check with a "-phongdebug" compile and set r_lightmaps 1 in the engine to see what is getting smoothed. 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.