Thanks!

No problem, I can wait. 

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

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. 

�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:
screenshot

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. 

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. 

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 (https://github.com/id-Software/Quake-Tools/blob/c0d1b91c74eb654365ac7755bc837e497caaca73/qutils/LIGHT/LIGHT.C#L13), so substituting:
angle = (1.0-0.5) + 0.5*angle;

And evaluate (1.0-0.5):
angle = 0.5 + 0.5*angle;

https://github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L403 

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. 

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