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? 

That's good.

func_detail_illusionary would actually be really useful to simulate crouching. The real ground would be lower, with a func_detail_illusionary ground a little above. Of course, this would affect monsters too, so its usage may be limited to small areas. 

I don't care much about quicker VIS times; all I want to achieve is phong shading and occasinally minlighting on brushes without taking up additional entity/model slots. Although marksurfaces eventually forced me to turn many of them into func_wall after all.

As for the issue I mentioned above, there's a workaround. As it turns out, phong and minlight also work on func_group, so making the big face a group instead of detail gets all the effects without the PVS problems. Good to know, albeit even more hax... 

Is there a way of increasing the lightmap resolution? 

texture scale is linked to the lightmap resolution. 

LIT2 (see the opening post) supports increased lightmap resolution and we all went round the block with it a few years ago. No clear community consensus formed.

My own opinion is that it's a poor trade off for hugely increased file sizes, and it doesn't even look as good as you'd think owing to losing the soft edges on shadows. 

It could be useful to add a compiler/worldspawn option to set portal brush contents to CONTENTS_EMPTY, because as it is, using CONTENTS_WATER, portals can't be (partially) placed inside of slime and lava. 

By the way, Quake's episode 4 already has maps with underwater portals. So, allowing portals under slime and lava would bring more feature consistency to mappers. 

Used black for its teleport texture.

I think you mean teleport. Portal is something created by vis.

That's not a terrible idea but I think it would serve better as an entity field: _overridecontents 1 or something to that effect.