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? 

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 http://filmicgames.com/archives/327 for something of a discussion. 

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. 

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

_dirt_off_radius
_dirt_on_radius

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. 

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. 

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? 

 

higher def light maps sound like they'd be useful 

 

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. 

Yes, what mh said. See here for the start of a discussion on it when it was trialed: http://www.celephais.net/board/view_thread.php?id=60967&start=382

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. 

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