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. 

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?

http://i.imgur.com/q1gWtTZ.png 

Aha, should be "-splitturb" without the "s"..
qbsp should be printing an error about unknown option I think? 

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

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.