sounds like an AI chat bot I can get behind. Maybe Microsoft can make it their next project after Tay failed.

"ur avin a giggle m8"
"u wot ill fukin slap u" 

doesnt seem desirable to me to always have an object fully phong shaded. I think there should be a way to choose to either have the model phong shaded or certain textures. 

Dunno, I think with the angle cutoff and the fact that you can break it down into as many func_groups or func_details as you want, the current system seems pretty ok?

I'm just trying to envisage a scenario where that's not enough, and I'm struggling.... 

complex func_groups like this -
https://twitter.com/GavinEdgington/status/714465169649377281

Where I don't want to have to break up into small groups because it will make it a pain to move around and place. 

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?