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

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. 

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. 

Is so Tron. 

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?