The angle cutoff is pretty flexible, if you set it to a low value like 30, only pairs of faces with normals up to 30 degrees apart will be smoothed together. So I imagine something in 30-60 would work well on that spaceship, and not add smoothing in unwanted places.

Also it's easy to check what the phong shading is doing, just compile with the light flag -phongdebug.

I could add back the list of textures to restrict phong shading to, if it's really needed, though. 

You guys are fighting the engine's weaknesses instead of playing to its strengths. Some things you're just not going to get control over without fundamental data format changes.

Pick what game you really want to be mapping for first. 

We'll continue working with quake and seeing awesome new tools to use and extend the life of the game. 

Was that a screenshot of something in an existing released map?

(Or what was that a screenshot of?) 

map in development for AD. 

When trying to compile the vanilla GPL start.map:

*** WARNING 10: Reached occupant at (386 1554 132), no filling performed.

This error happens in a lot of places with the vanilla .map files. 

you use the tyrutils qbsp? I guess so, this thread gives me the clue..

I tried to recompile those vanilla maps myself some time ago, several compilers had problems with them.

Whats the cause of those? I don't know, the map were rather tidy in my eyes, all integer coords and such. We all know there aren't any fancy brushes in them. 

try -oldaxis switch? 

-oldaxis didn't help. Time to read the docs... 

try the first released qbsp.exe. Quadicted should have it archived. 

thats an old version, only watervising added to it.

https://www.quaddicted.com/files/tools/wqbsp165.zip 

According to the WQBSP165 docs, it doesn't support -splitspecial, so lit water won't work with it.

The problematic entity is a light torch; I've tried deleting it and creating a new one at the exact same place, and the problem still happens. It's like the tyrutils qbsp compiler is too strict about entity placement.

Light entities should be treated as point entities by the QBSP compiler. I wonder if the tyrutils qbsp is checking whether some default bounding box size is out of map bounds or something. 

weird, can't reproduce here.
I have a START.MAP modified 4 Sep 1996. No leaks with qbsp.exe from tyrutils-ericw-v0.15.4-115-gfff8cbf. Adding -splitspecial doesn't cause leaks, either. 

o_O

rebb? eric? carmack? any ideas? 

Anyway, I've confirmed that my code for lit water wasn't implemented. -lightturb doesn't make any difference.

See the result with tyrutils-ericw-v0.15.4-115-gfff8cbf: scr_0778.png

And the proper result with my old modified build: scr_0779_mankrip.png

So, there's still no way to compile maps with both lit water and smooth shading. :( Oh well. 

I forgot about http://forums.insideqc.com/viewtopic.php?f=12&t=5769

But I'm confused.. now I realize that -splitspecial means water won't have TEX_SPECIAL set. This means lit water should "just work" without changes to light - so the -transwater stuff Spike added is unnecessary. Your patch just makes the bottom face receive light from above, rather than underwater, right? That seems sensible since typically most of the light sources will be above the water, but not having that shouldn't cause the artifacts in your first screenshot. 

all I can say is that the water parts of my patch were completely untested, and only half written. yeah, I got bored and then forgot about it, okay? please forgive my sins! so that I can more easily commit them in future! mwahaha!

the bright part of the water is probably a poly with no lightmap info at all (which technically means all-white-but-not-overbright instead of all-black when found on water surfaces).

this would imply that much of that area is normally lit from below.

I don't think it tries to subdivide water either. I guess this means that the controls for whether water should be lit should really be inside the qbsp instead. 

Your patch just makes the bottom face receive light from above, rather than underwater, right?

It makes each face receive light from both under and over the water, to match the lighting on the nearby walls. The normal inversion is done on a per light entity basis - the face's normals will only be inverted for light entities behind it.

now I realize that -splitspecial means water won't have TEX_SPECIAL set. This means lit water should "just work" without changes to light

-splitspecial also splits the water surfaces into the appropriate size for lightmap creation.

typically most of the light sources will be above the water, but not having that shouldn't cause the artifacts in your first screenshot.

As mentioned at InsideQC, my code includes a hack to force liquid surfaces' lightmaps to always be saved, otherwise fully dark liquids would remain fullbright. 

It would be better if the -splitspecial option in the qbsp was replaced with -splitturb and -splitsky options. There's no need to split sky surfaces, because there's no need to make them receive regular lighting. 

It makes each face receive light from both under and over the water, to match the lighting on the nearby walls. The normal inversion is done on a per light entity basis - the face's normals will only be inverted for light entities behind it.
Ok, cool, I'll try merging this in.

As mentioned at InsideQC, my code includes a hack to force liquid surfaces' lightmaps to always be saved, otherwise fully dark liquids would remain fullbright.
I think this bit is missing from your patch?
This does seem like a hack around an engine bug... There shouldn't be any ambiguity; in an engine supporting lit water, a face with face->styles = 255, face->lightofs = -1, TEX_SPECIAL unset, and texture name starting with '*' should be rendered black, right? 

This does seem like a hack around an engine bug... There shouldn't be any ambiguity; in an engine supporting lit water, a face with face->styles = 255, face->lightofs = -1, TEX_SPECIAL unset, and texture name starting with '*' should be rendered black, right?

It's not an engine bug, the lightmap data is missing from the BSP file itself. For some reason, if no lights touches a liquid surface, no lightmap data is generated for it. I've studied the light.exe code for hours and couldn't figure out what causes this, so I've just forced the lightmap data of liquid surfaces to always be generated.

With no lightmap data, the surface cache for the lighting can't be created.

I think this bit is missing from your patch?
It's not missing, I've just implemented it in a subtle way:

/* don't bother with light too far away */
if (dist > entity->fadedist)
if (!backwater) // mankrip
return;

This allows far away lights to be casted on liquid surfaces, therefore forcing the lightmap data to be generated - even though far away lights won't add any brightness to it. 

It's not missing, I've just implemented it in a subtle way
Ah, I see :)

It's not an engine bug, the lightmap data is missing from the BSP file itself. For some reason, if no lights touches a liquid surface, no lightmap data is generated for it
This is not specific to lit water.. light.exe will not write fully black lightmaps to the bsp. It was a compression / optimization in the original light tool and engine; lightofs of -1 is rendered black. You can see this by deleting all lights except a small dim one in a large map, the lightdatasize will be only be a few hundred bytes.

here's the early exit in light: (f->lightofs = -1; is set earlier)
https://github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L542

and places where it is handled in the engine:
sets surf->samples to NULL if face->lightofs is -1:
https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/gl_model.c#L795 

This is not specific to lit water.. light.exe will not write fully black lightmaps to the bsp.

I know this.

I don't remember all the details on why the lighting for liquids couldn't be generated if the light data wasn't present in the BSP file, but I will take a look at it again later. 

Alright, I've had some sleep.

Here's the proof why the lightdata for liquid surfaces must always be generated. In Mod_LoadFaces:


if (!Q_strncmp(out->texinfo->texture->name,"*",1)) // turbulent
{
out->flags |= (SURF_DRAWTURB | SURF_DRAWTILED);


The SURF_DRAWTILED flag in the engine is similar to the TEX_SPECIAL flag in the tools: it serves to indicate that the surface shouldn't have lightmaps. And it can't be eliminated, otherwise maps compiled without -splitspecial will crash the engine when trying to generate the surface caches.

Right now, I'm using an if(!out->samples) statement to ensure that maps without lit water will have the SURF_DRAWTILED flag set. However, the engine loads the mtexinfo_t data through Mod_LoadTexinfo right before Mod_LoadFaces is called, so in theory it should be possible to replace the (!out->samples) check with a (texinfo.flags & TEX_SPECIAL) check.

I'll modify the light tool to remove the "always save lightdata" hack, compile a map with it and change the check in the engine to see if it works. 

Yeah, it worked. Now instead of this:


if (!Q_strncmp(out->texinfo->texture->name,"*",1)) // turbulent
{
out->flags |= (SURF_DRAWTURB | SURF_DRAWTILED);


... the proper way to set SURF_DRAWTILED is this:


// mankrip - begin
if (out->texinfo->flags & TEX_SPECIAL)
out->flags |= SURF_DRAWTILED;
// mankrip - end
if (!Q_strncmp(out->texinfo->texture->name,"*",1)) // turbulent
{
out->flags |= SURF_DRAWTURB; // mankrip - edited


:) Thanks for making me look into this.