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

http://i.imgur.com/1poBXfp.png 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: http://i.imgur.com/y6JHK4r.png

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. 

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

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? 

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. 

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)