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. 

I managed to come up with a solution that works...

I've made just the visible faces have the texture that needs to be smoothed. This seems to only work with indoor lighting though. I do hope it can be applied to outdoor lighting too since I don't want to go back to the horrible method of lighting prior to sunlights.

Here's an example that shows the difference between phong shading and normal quake lighting -

https://twitter.com/GavinEdgington/status/675802921334915072 

The pipes have lighting issues if anything but the visible faces have the smooth texture. I made the non-visible connecting faces use a skip texture to avoid these errors. 

Ah, I see what you mean Fifth, sunlight is not phong-shaded. I'll see if I can fix it. 

It's not perfect, but it's a lot better than the standard lighting.

Another bonus point is that now I can wait some more time before developing my own approach. There are lots of things to do� 

Editor support could get messy. It would probably require messing around with FGD files to convert Quake entities to Q2 entities� or convert the Quake FGD to the Q2 specs.

I know about the differences between Q1 and Q2 BSPs, but never thought about looking into the differences between their .map formats. 

is certainly not perfect and I would want to be able to have _smooth work with other brush types like func_group etc. 

@mankrip
afaik .map format doesn't have that many differences, just 3 extra args. brush contents, face flags, and face light level.
tyrlight already parses q2 maps and generates q1 bsps, however it completely discards the extra 3 args (also, no value texture alignment tweaks).
I don't see why you'd need q2 fgd changes at all, you'd still be targetting q1 mods and tools, and editors that support both would likely continue to support both without really caring.
the real issue is 1) editors that do not support quake2. 2) editors that insist on using wal files instead of wads. 3) editors that assume the palette is that of quake2 instead of quake.
for the editors that are mainitained tbh all it requires is for someone to be vocal enough - its amazing how much of a motivator harasment can be.


@ericw
I didn't change anything to do with sunlight that I remember, so yeah, no support there.
sorry about any other issues with it too. I was going to sit on it while someone else found the kinks for me, before making it public.
but, well, open source matra: release early, release often. I'm too lazy for the second part though.
by releasing I hoped to at least save some time for mankrip.
in theory it should be possible to switch the barrycentric coords part to use the entire polygon instead of a triangle (giving a less-triangular/higher-quality apearance), but I just went with what I understand.

@Fifth, there's nothing specific about classnames, it ought to work with any classname (at parse-time, on account of the way it flags texinfos). certainly there's nothing specific to func_detail.
all I can really suggest is to make sure that there's no tiny cracks between faces, because it calculates normals at each vertex and then just interpolates those over the various triangles that form the surface in a similar way to how a gl engine would interpolate normals.
remember that it'll happily smooth around any angle, 20 degrees, 90 degrees, 170... this means you'll likely want to use some other texture for the top/bottom of your mid-pipe cylinders so that they don't cause it to try to curve around those rings. secondly, sunlight isn't supported right now.

if you're looking at the map in fte or dp, make sure you disable any specular first. the texinfos are flagged to say that normals should be interpolated, but engines don't understand that yet, and yeah, I forgot sunlight, and there can still be harsh (often mid-surface) boundaries due to the maths behind the anglescale thing (at one point I was toying with the idea of these surfaces just always using a value of 1). 

I fixed a few bugs that were causing black fringes in my phong test map, and added support for phong+sunlight.

Here is a build: http://quakespasm.ericwa.com/job/tyrutils-ericw-spike/3/artifact/dist/tyrutils-ericw-v0.15.3-7-g05de1ad-win32.zip
and the source code:
https://github.com/ericwa/tyrutils-ericw/commits/smoothnstuff

Hopefully this works on your map, Fifth!

Note, this is based on the previous release of tyrutils-ericw (0.15.3), I'll need to do some merging later on. 

I'd add support for Quake 2 map in Quake games in a jiffy. Would be really easy too.