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. 

Yea that does look usable indeed! Sign me up for that :) 

In the words of Daz, "you are a fuck". 

Aye that's the biscuits, nice one :) 

awesome! 

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

I guess it depends on the end result. If it looks good enough, it might be worth it. 

i've got this error
what gives?
dp engine http://quaketastic.com/files/screen_shots/dp_error.png 

Does it work in a normal Quake engine without mods? 

i guess it's somewhat related to an fte compiler, with its all optimization turned on

i'm just wondering what the hell is vm_vlen 0/1 

basically, when i'm running quake/mod via fitz(for example) it runs fine
when i'm running quake via dp it runs fine,

and when i'm trying to run the mod using DP, it crushes (vm_vlemn)