Moving all features that affect the world into entities would be neat.

"sky_fog" entity or something for easily copying fog between maps, etc... 

Suggestion: use the classname "info_world". 

And "info_world_sun", "info_world_fog", etc. in case of different entities for different features. Just to make it clear that such entities are global effects, not local effects. 

When are we getting phong shading?! WHEN?! 

If EricW doesn't implement it, I will.

But a proper implementation will most likely require surface flags (or, more specifically, surface groups), and the actual algorithm may not be Phong shading, but something that looks similar. There are a number of design issues to consider.

This is one of the features that I've been thinking about during this whole year, and it's not simple. 

And when are we having radiosity? Oh Lord, when? I wonder... 

for organic geometry how about something like "func_detail2" or "func_group2"? Something outside the regular thing that just applies it to a whole brush? 

I know it would be more ideal to apply it to surfaces but I would love to see something, *ANYTHING*, in the mean-time. 

better to have a key:val on any func entity

e.g.

_smoothangle: 15

That way you can control which faces get smoothed based on angle. 

I would be all in favour of Quake 2 style surface flags... I know it's introducing a new format for Q1 but at this point does it matter? 

I would be all in favour of Quake 2 style surface flags... I know it's introducing a new format for Q1 but at this point does it matter?

You have to think about compatibility with editors like netradiant that are no longer being updated. 

This would create yet another legacy feature that would become redundant and require extra work to avoid conflicts and retain compatibility with.

Plus, most of the work I need to do before developing my approach is to implement a bunch of BSP debugging features in the engine, in order to analyze and tweak things properly without blind trial and error. The smoothing algorithm itself shouldn't require much time afterwards. 

q1rad 

What's the deal with q1rad? Does nobody use it because it doesn't have all of Eric's latest jingles and jangles or does it not really work all that well? 

It is essentially the hl1 light tool ported to Quake.

The problem is that the final results can be quite washed out and lack contrast. I lit crdm2 with it and looking back now, oh god the lighting is awfully dull! 

the q2 light tool supported radiosity too. default 8 bounces, max 40. in retrospect, the best looking option would have probably been -bounce 1, which is what I'd use for quake if we had it (one pass of scatter and that's it). since Q2 came out when I was young and dumb I thought -bounce was one of those parameters that you set to the maximum when you do your 'final compile' so I basically released two needlessly washed out yellow Q2 maps.

vrad for source just does the max number of bounces it can, and when it runs out of light it stops, but their scatter and falloff equations were probably adapted out of a real optical physics textbook by an in-house mathematician they pay a half million dollar salary, so it always looks perfectly real in HDR. 

http://triptohell.info/moodles/junk/tyr_smoothnstuff.zip

adds a _smooth key to your func_detail entities that smooths the normals across surfaces.
you might want to use -anglescale 1 or the equivelent field in order to prevent quake's harsh boundaries between lit and unlit areas.

the qbsp flags the various surfaces. it doesn't currently support smoothing groups, but it would be the qbsp that would need to generate dupe verts for surfaces with different groups (this ensures that engines with specular effects can work correctly).

also adds a few other things that I've been messing around with. check the readme (be warned that much of the extra stuff only works with fte, but not always to the detriment of other engines - _lmscale has a well-defined fallback).

there's probably other issues with it - I'm not the intended audience so I'm kinda lazy where it comes to testing.



per-surface flags would be really nice right now... but yeah, map editors. 

Will check it out in a bit 

not sure how it works..

I made a key in my func_detail as _smooth and put the texture name in the field but it doesn't do anything? 

I'll take a look at it too. 

I'm trying to make the big pipe in the middle lit smooth... even with this util I am not getting smoothing.

http://www.quaketastic.com/files/screen_shots/5thnophong.png

Any ideas? 

It's working for me: http://imgur.com/a/8KLPX
That's with just one light entity, "_anglesense 1" set, delay 3.

What kind of light sources are lighting the pipe currently?
If it's _sunlight, try adding "-anglesense 1" to the light command line, this controls how much sunlight (only regular sunlight, not _sunlight2) is affected by normals, 1 is the maximum amount.

Sunlight2 ignores normals, so try turning it off if you're using it.

You're running both spike's qbsp + light? 

I just tried it on an indoor area and it seems to work. It's not quite as good as the smoothing in Quake2's tools. I get very weird lighting on pipes for example (it's smooth but it doesn't like pipe bends and I'm getting harsh results) 

i'd imagine with some polishing it can be made to work as well as Q2's, the Q2 tool source is available too. 

I haven't given this a whole load of thought, but just wondering how much of a big deal it would be to just use the Q2 .map format but compile it to a Q1 .bsp format.