The linked version (http://www.icculus.org/netradiant/files/netradiant-1.5.0-20120301-win32-7z.exe) doesn't work for me.
I still get this: https://i.imgur.com/DwU4XQr.jpg
Usually nothing happens afterwards.
Sometimes it starts but crashes after a short while. 

I think it hangs like that for a long time when you start it up for the first time.

Have you tried just letting it sit like that for a bit?

After the first time, it should start up normally. 

well, if you do wait until it starts, but it then crashes, then I dunno. 

Sometimes it seems to work but the 3D viewport and some hotkeys keep glitching.
I can't find the problem... 

Any of the LIGHT.exe tool developers planning on adding "smooth" "phong" shading support to their compilers? Light smoothing / samples and widening angle doe do a lot but I would like to have a little more control in that regard. Smooth shading 8 sided pipes for example would be nice :)

Please correct me if this is TOTALY in the wrong thread. Apologies ahead of time if it is.

Thanks! 

How would you control it? If you just set a level-wide smoothing angle you'd get smoothing all over the place and not just on your pipes. It was easy for Arghrad in Quake2 because you could set per-surface light values, and the hack was that if you set a value but didn't check the 'emits light' flag it would treat the number like a smoothing group. Since Quake has no such thing, that would basically mean using either texture prefixes or something like func_smooth, which both sound kind of awful. 

I was thinking not a seperate func, but a key/value that works on any func - like a _smooth property

To use on world geo, you'd put your chunk of world geo in a func_group, or a func_detail I guess. 

actually specifying per-surface values was pretty awful so i wouldn't mind having using a func_group (or func_smooth) instead. Sure it would be less flexible (can't mix smooth and hard on the same brush) but it would be much faster to set/verify which brushes will be smoothed. 

I would be curious to try that approach since the per surface value is missing in Q1. 

just increase side count to 32?
And r_speeds be damned! 

(can't mix smooth and hard on the same brush)

Maybe you meant something else, but if the smoothing is governed by a "smooth angle" key, then you could get hard and smooth on the same brush surely.

Anyway, a complication with the func_ approach is that the lighting has to be done once BSP has had its way. At this point you'd have lost your func_group data surely? And really, we'd need this to work on world geometry or it would be pretty pointless. 

And if you want hard and smooth shading mixed on a brush then you will just have to use multiple ones.... Then again having a range on the smooth key could still work.

A pipe that is 8 sided but with a cap would shade smooth on the 8 sides and flat shaded on the cap if you set the smoothing threshold to 50.

Those 8 sides wont go past 45 and the cap is a 90 degree angle.

I would include 2 values though. one for the degree threshold and another for groups simply controlled by another number. That way you can have brushes smooth next to each other but if they don't share the same group they smooth on their own and ignore their neighbor.

its basic and does not allow for more elaborate mixing though. 

Anyway, a complication with the func_ approach is that the lighting has to be done once BSP has had its way. At this point you'd have lost your func_group data surely? And really, we'd need this to work on world geometry or it would be pretty pointless.

Yeah, you couldn't do it in the traditional way. Possible workaround 1: emit some kind of e1m5rmx.smo file in the bsp pass which contains the relevant smoothing data for the lighting pass, no smoothing if it's absent. Possible workaround 2: Create what might be the first hybrid bsp and light compiler which could remember the smoothing info...

Since you can't really process any lights until the bsp is complete, I'm not sure that option 2 would really be simpler than option 1. 

I'm surprised nobody has done a monolithic compiler app ... one that does it all in one shot - with the possible benefit being what you mentioned, each process being able to have knowledge of what the earlier ones did. Although I guess there's little benefit so why bother? 

AO baked into the lightmaps AKA the way CS:GO does it. AO would look awesome with brush architecture but the few engines I've tried to force it "on" in doesn't work. 

If there was any way to hack in higher resolution lightmaps that would be lovely too :) 

Something I thought about but never tested was creating 2x size versions of all the textures you are using in the level and then set the default texture scale to .5 so that you would have double resolution lightmaps across your level.

Unsure how it would look/work and some textures would probably be too large at 2x size. 

What's AO lightmaps? 

http://en.wikipedia.org/wiki/Ambient_occlusion

Doing it as a lightmap means just making extra shadows in corners. Q3map2 has an option to do something like it in Q3. http://en.wikibooks.org/wiki/Q3Map2/Light#-dirty 

Do quake lightmaps have enough resolution to support a -dirty AO effect? I guess hence your question regarding higher res lightmaps?

In the old days, I tried this and it does work to give you higher res lightmaps, but you would run out of lightmaps pretty quick.

Of course, these days, there are a lot more lightmaps available... 

Wish we hadn't called it "dirtmapping" in Q3Map2, but back then pretty much the first popular incarnations of AO were "dirtmap" shaders for 3D apps that were used mainly as masks for gunk and dirt in corners. 

"Something I thought about but never tested was creating 2x size versions of all the textures you are using in the level and then set the default texture scale to .5 so that you would have double resolution lightmaps across your level. "

That's ... a really cool idea! 

so that you would have double resolution lightmaps across your level.

and presumably quadruple the face count, but i'm guessing no-one cares? 

oh right, that was another problem with doing that. 

Just tried to frankenstein the "-dirt" code from q3map2 into tyrutils, and it looks like it could be usable!
http://i.imgur.com/TbxbITN.jpg

(e1m1 with r_lightmap 1, light is just using the AO values and ignoring lights in the map file) Will tidy it up a bit and post a build tomorrow if anyone wants to play with it.