hmmm.... any link to proper LIT documentation? 

Hmm being able to read and write the lighting from and to BSP would be a rather fantastic addition but then you run into a world of pain if you want more light styles supported. how to handle flicker lights and so forth because those get layered on top and limited to the polygons they affect if I remember correctly.

As for the _bounce you could do that or just add it to the compiler as a global option. Same goes with bounce multiplier and saturation. How much energy is maintained when it bounces and how much color is picked up when it hits the surface. In Unreal you can tweak these values so its more saturated and propagates lighting further by not losing as much energy on the first bounce. 

yeah, I know about light styles being problematic in this situation. I'm going through source to fully understand how it works. 

As for the _bounce you could do that or just add it to the compiler as a global option.

Then make it a worldspawn key, so that way lighting could be easily recreated at any time and by other tools without needing to know the command-line options that were originally used.  

There is a port of the half-life 1 radiosity lighting tool to quake 1 you could look at? It does bounce and phong but lacks modern features from these tools... It's called q1rad. No link sorry I'm mobile 

 

Beta builds are moved here for now, if anyone wants to try the update phong shading.

The documentation isn't updated yet, but the readme.txt has the details on phong. basically set "_phong" "1" on func_detail/func_group/func_wall etc. 

beer@ericw.com 

Does this one include lit water support? 

Yes, spike added it, but it's untested.
There are these command-line options:
[-lightturb] [-lightwater] [-lightslime] [-lightlava] [-lighttele]

-lightturb just is a shortcut for water + slime + lava + tele. 

This is just crazy, so much advancements to ole Quake! Thank you all for the efforts, really...can't be said enough. 

btw, the key for phong shading has changed since the version you were using, you no longer need to give the texture name. The main improvement of this new version is having an angle cutoff, so it won't smooth around 90 degree corners by default (the cutoff is 89 degrees.)

Another new feature: when using phong shading I suggest setting "_anglesense" "1" in worldspawn, this affects all lights in the map that don't override "_anglesense".
This will make phong shading more visible and generally increase contrast.. it makes the angle that light arrives on a surface matter more than the quake default. 

I'm not sure I will change compilers unless I am really compelled to 

 

Does it apply phong shading to the whole brush? Not sure if this is desirable behaviour.

The thing I want most is a more tolerant or forgiving compiler like txqbsp 

 

whats your problem?? 

my brushwork sucks and I guarantee once my map is properly "sealed" it will leak like an incontinent old man who just drank 30 litres of water. 

 

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.