using caulk for casting shadow is equivalent to advocating the use of csg subtract. caulk only casts shadows if it’s structural. if you’re approximating a patch with caulk, you’re creating a bunch of portals, making a messy bsp, and lengthening vis times. -patchshadows is the only way to go.

16-bit color buffers sometimes use 5-6-5 format, where red gets 5 bits, green gets 6 bits, and blue gets 5 bits. green light is more luminous, so it gets the leftover bit. the downside to this is that it can’t accurately reproduce gray shades other than black or white. they will always have a tint to them (green or purple).

if you’re using “tainted” editor images for your shaders, don’t forget to add a proper q3map_lightimage as well. radiosity will otherwise reflect the editor image texture rather than the true color you intended.

interesting map. i like your eye for colors/lighting, Tems. a couple suggestions, if i may:
lose the ambient light and use radiosity (-bounce N) when compiling the map. be sure to use fast as well, and maybe -filter, to soften out the stair-stepping.
if you’re using q3map2 to compile the map, consider replacing the sand/floor with a triangle brush mesh using a shader with the following:

q3map_nonplanar
q3map_shadeangle 75
q3map_lightmapaxis z
q3map_tcGen ivector ( 256 0 0 ) ( 0 256 0 )

a shader with those parms will stitch together adjacent triangles into a smooth shaded mesh, with the texture coordinates automatically generated (projected on the z axis, every 256 units in the x and y directions). note that this shader should only be used on floor/ceiling surfaces because of the explicit texture projection.

ydnar> the way vertex light works is that it takes the vert, looks at the lightmap, and finds the closes non-occluded, brighter-than-ambient sample and uses that. if one isn’t found, it searches outward in a radial pattern and averages.
bdogg> ok
ydnar> since those verts are lying on non-occluded dark spots, it never searches outward. hence the dark verts.

jer> wow, the vis job this thing did is amazing. throwing hint half-way down from the top-most sky brush to mid-terrain, and caulking inside the mountains. freaking rad, now that it doesn’t draw so much. now I’m confident i can go on mapping.
cloudscapes> it really does a good job i agree. now one of my older maps runs at a peak of 230 fps in two areas, as opposed to 90 with the old version. freaking insane.
ydnar> btw. for final compiles, remove –nogrid, and add –extrawide.
dotExE> what does that do?
ydnar> -extrawide does 4 samples per luxel, and filtering
dotExE> and also i should remove both the fast switches
ydnar> no. not from light.
dotExE> oh, okay
ydnar> you don’t want to remove it from light, trust me
dotExE> heh

ydnar> ent lights = point lights. area lights = surface lights.
mmz_sp4wn> so point lights aren’t what to look out for? for compile time
ydnar> area lights are much slower & they are more expensive to calculate. -fast alleviates that problem to a degree. big, small, tidy, bright, dark, whatever (maps)
mmz_sp4wn> so what should i do to get rid of so many lights? does lighted sky and lighted water make a lot of lights or just 1 apiece?
ydnar> your map obviously has tons of light emitting surfaces. depends. q3map_lightsubdivide affects that. it’s pretty efficient when packing lightmap pages.
mmz_sp4wn> q3map_lightsubdivide 32 for my water
ydnar> whoa. heh. how much water do you have? is there a lot of visible water?
mmz_sp4wn> quite.
ydnar> ok. that’s where your light glut is coming from. it’s chopping it up into 32x32 chunks. that adds up quickly. you do the math.
mmz_sp4wn> i need to have light in there
ydnar> what’s the light value for the water? and why should it emit light anyway? that’s what radiosity is for
mmz_sp4wn> q3map_surfacelight 75
ydnar> very dim. nuke the surface light completely. get rid of all of it.
mmz_sp4wn> and i should make my own sky shader
ydnar> mmz_sp4eah, but use a reasonable subdivide on the sky, like 512 or 384, btw
mmz_sp4wn> ok. the sky is almost 1900 by 2500
ydnar> 6? 8?
mmz_sp4wn> surface
ydnar>use a subdivision of 384, that should be solid.
mmz_sp4wn> ok, so, the lower the subdivide number the more lights it has?
ydnar> yeah
mmz_sp4wn> ok
ydnar> think about it this way. subdivide is a measurement. if you subdivide your wall into 10-inch squares, it’ll be a lot of squares.
mmz_sp4wn> so 32 would be every 32 square units is 1 light.
ydnar> yup
mmz_sp4wn> i got it
ydnar> 1 area light. which is slow. especially if you compile w/o -fast.
*ydnar thinks about putting in messages in q3map: “you have a lot of area lights in this map. consider using -fast next time.”

Vexar> well it would cause me to add unnecessary lights if i used it all the time, then when i did the final it would be to bright
ydnar> well, fast isn’t like -vis fast, it’s good enough for final
Vexar> oh understand
ydnar> it’s just “dimmer” because it does some optimizations. is the map fullvised, btw?
Vexar> i know what you mean. will the level get lighter after all the radiosity is done?
ydnar> yeah, lighting will get brighter with each successive pass as light gets bounced around. think of fast as another lighting mode entirely.

ydnar> 3 things make shadows:
ydnar> *structural brushes
ydnar> *patches
ydnar> *surface triangles
{wf}shadowspawn> right
ydnar> if you can draw a line between a point and a light w/o hitting one of those, then there won’t be a shadow.

ydnar> just use caulk
{wf}shadowspawn> detail caulk faces don’t block light
ydnar> um
ydnar> 3 things make shadows
ydnar> *structural brushes
ydnar> *patches
ydnar> *surface triangles
ydnar> you’re right, they don’t block light on their own. but there is a ceiling in that building, right?
{wf}shadowspawn> their face to the light source doesn’t either
ydnar> nope, myth. that code was nuked a long time ago. doesn’t matter, if a surface is in the way, it creates a shadow, btw
{wf}shadowspawn> oh
ydnar> black, blendFunc add is not a very nice way to have an invisible surface =)
{wf}shadowspawn> yea it was an experiment
ydnar> yeah, Mr.E wrote some backfacing stuff into the raytracer some time ago. it was commented out, and i simply nuked it while cleaning house. it’s simply not a valid assumption.
{wf}shadowspawn> i have another white tga with an empty alpha for making invisible light emitting stuff, but that’s play stuff too
ydnar> you don’t even need that

ydnar> r_lightmap 1 is a good way to see how effective radiosity is.

ydnar> run -light fast -nogrid -debugunused and then noclip around the map
laerth> k
ydnar> well, run around the map, and see if you can see any hot pink action.

]s[belac> does q3map_(no?)bounce mean light emitted from this surface doesn’t bounce, or light doesn’t bounce off this surface?
ydnar> it means that it doesn’t bounce light. there’s no way to separate light from different sources in radiosity, it’d take too much memory.
]s[belac> ok so my second assumption then. light won’t bounce off the surface

{wf}shadowspawn> autosprites don’t emit light anymore, right?
ydnar> yeah they do, but they are point lights

]s[belac> why doesn’t my grass have lightmap showing like the rest?
ydnar> it’s a shader, yes?
]s[belac> yah
ydnar> only defaulted shaders get that functionality. unless lightmap is stage 0, and everything else is afterwards.
]s[belac> ah

jer> ydnar is _lightmapscale okay to set in worldspawn?
ydnar> yeah
jer> i thought it was like _samplesize or something, or was that something else?
ydnar> no, _lightmapscale scales the samplesize. a little more flexibility

ydnar> maybe i need to crank down the lightmap compression a bit more
jer> oh, and it was awesome too
ydnar> filter?
jer> yeah filter, but cause the bsp size with the scaled lightmaps was smaller. i went from 30 some-odd lightmaps to like 12, between _lightmapscale on worldspawn and a select few func_groups
ydnar> hmm
jer> and the func_groups looked way better
ydnar> yeah. _lightmapscale is good when selectively used.
jer> when i did it to worldspawn, it didn’t seem to take effect exactly?
ydnar> _lightmapscale 2.0 is good for worldspawn
jer> that’s how it looked. yeah
ydnar> worldspawn only affects ungrouped brushes in the worldspawn entity
jer> ah, so func_groups will have their normal values. that makes sense, cause they don’t specify it, and they wont inherit it from worldspawn (their own entity outside of worldspawn)

h0rst-ds> what’s a good line for a preview compile ? -cheap fast ?
ydnar> sure, but i never use -cheap anymore.

{wf}shadowspawn> smooth. very smooth shadows.
str0ngarm> ydnar added a 1-2 pixel gaussian blur to shadows
{wf}shadowspawn> yea
str0ngarm> very nice from what it sounds like =]

ydnar> you have to supply shade angle. either in a shader, with q3map_shadeangle.
hro|away> ahhh
ydnar> or cmdline -shadeangle
{wf}shado|upped> yea it didn’t work for me either yet though; i used 68 though
hro|away> maybe time to make a readme?
{wf}shado|upped> 16 sided brush
jer> ydnar shadeangle in func_group?
ydnar> no, no ent keys yet

jer> you can specify thresholds in your shaders, instead of a global threshold. that’d be where the power of thong is at, if I'm correct. err, forgive me. phong.

ydnar> turned off the ambient light, so most of the map is just sun lit
{wf}shadowspawn> yea i tried that. its ok, still need to work on the water though. heh. added the subdivide and the surface light like u mentioned, 16 bounce though. wow.
ydnar> you added subdivide + surfacelight to your sky?
{wf}shadowspawn> yes
ydnar> you need to remove nodraw from it to get that to work
{wf}shadowspawn> yea, that’s the reason for that fake hack... err fake nodraw hack, that totally transparent image. but can’t i remove that pass after the map compile, and make it nodraw?
ydnar> here’s what you do:
ydnar> {
ydnar> map $whiteimage
ydnar> blendFunc gl_zero gl_zero
ydnar> }
{wf}shadowspawn> I'm grinning

ydnar> ambient sucks. don’t use it. you need to crank up the surfacelight a lot 60 ain’t doing shit. try 200 and add q3map_lightsubdivide 512 too.
pointy> k. what about my gridsize in worldspawn? 128 128 256 at the moment.
ydnar> that only affects ents. does tracegrid() take a while?
pointy> not on fast
ydnar> ok you may want to add a lightgrid brush

jer> cardigan you can make any sun shader you want, and it will place itself where q3map_sun is.
cardigan> can you?
jer> cardigan excellent work-i look forward to playing it
cardigan> wow!
jer> yeah
cardigan> how
jer> hold on, ill tell you how. i have a sun shader. its an autosprite. then in your sky shader, (sunshader shader>) point to your sun shader or image most likely a shader i just did a blendFunc add on the sun.
cardigan> thanks, that’ll do nicely - save me having to line up the light direction
jer> one thing though
cardigan> ?
jer> i think the size is a fixed sprite size, so your sky portal might be a better idea, if you have a giant earth sprite in your sky portal, but some experimenting to do, nonetheless
cardigan> indeed
ydnar> cardigan it doesn’t have to be an autosprite, since the camera point is fixed. you can just put it on a face.
jer> i think so-i was going off of gmi’s moon shader.
cardigan> you get an interesting lens twist effect on the sun flare as you turn if its a sprite, looks pretty neat.
jer> yeah, i have tcMod rotate 5 for my sun. just so its a subtle change in the sky.

ydnar> yeah, fast tends to dim things down
Vexar> ok

laerth> ok. -light fast -bounce 3 -bouncegrid -filter -shade -shadeangle 89 -thresh .5 -super 4 -patchshadows

rtz> i want to see q3dm7 using phong shading or radiosity. what would be a good command line?
rtz> -light fast -extra -smooth -bounce 8 -bouncegrid
ydnar> bouncegrid is a don’t bother
ydnar> unless you really need it
ydnar> -smooth does nothing anymore
ydnar> -light fast -extrawide -bounce 8 is good
ydnar> maybe -shadeangle 45 too

ac3-jerk-3j> ydnar anyway to get the center lights to disappear on long brushes with surfacelight?
ydnar> ac3-jerk-3j add a q3map_lightsubdivide to the shader
ac3-jerk-3j> what values though? i have it in shader at 256, but seems to have no real affect, just creates more spots with some value.
ydnar> what? hmm. with a13?
ac3-jerk-3j> yup. instead of a spot in the center it may create 3 or 4 equidistant from each other along the brushface
ydnar> you can also set q3map_backsplash 0
ac3-jerk-3j> ah coo

johnny_rocket> yeah, it that shot it is
ydnar> wtf. ok. hmm. see if it happens w/o -filter. that looks like a filtering artifact
johnny_rocket> ok
ydnar> oh wait. are you using phong?
johnny_rocket> yeah
ydnar> err, -shade? yeah. phong shading + filter = weird results sometimes. you should use q3map_shadeangle in your shaders instead of a cmdline -shadeangle. there’s nothing i can really do about it, other than spend another month tweaking the code.
johnny_rocket> ok, that was both phong and filter. is one inherently going to be “better,” or will it depend on the map +lighting, etc.
ydnar> well, phong does some normal interpolation,  which can incorrectly light some surfaces. -filter averages values from neighboring samples, even if they’re “off” the surface. “off” samples have indeterminate surface normals, because there’s nothing to calculate them from. it’s a limitation of the fact that lightmaps are so low-res.
johnny_rocket> ok. I'm actually changing that geometry a little so some off that stuff will be off plane-it’s creating a ton of small splits
ydnar> heh. t-junctions.
johnny_rocket> tri-fans
ydnar> yup. which wackos phong shading. you could also omit -filter, and add -thresh 0.25, which means it’ll do more normal sampling/averaging. the maprawlightmap() will take about 2-3x as long though.
johnny_rocket> ok, so thresh affects -super
ydnar> thresh affects phong shading
johnny_rocket> that’s what overnight compiles are for
ydnar> nothing more really. think about it this way:
ydnar> super * 1.0 / thresh
ydnar> rather
johnny_rocket> one thing i learned about detail brushes is that they still cause splits if they are on the same plane as a structural brush
ydnar> super * super / thresh ~= number of taps per luxel in mapping stage.
ydnar> not splits, t-junctions
johnny_rocket> right
ydnar> if a vertex of a face meets an edge, that edge will be split. if you map cleanly, you can do -notjunc on the bsp line, which will suppress that, but you might have sparklies if you’re not careful.
johnny_rocket> t-junctions are then fixed by splitting a brush (not bsp split), right
ydnar> no. t-junctions are fixed by splitting the edge of a face polygon, and adding a new vert at the split point so it becomes a + junction.
johnny_rocket> ok, good to get my lingo straight the ydnar. under the old q3map, a brush with split polygons would still be one drawsurf, right? brush = polygon, might be a better way to put it.
ydnar> yeah. it still is, until the -meta process diffuses it into triangles, to be recombined later.
johnny_rocket> so you could potentially have fewer drawsurfs. I'm beginning to get this stuff i think.
ydnar> yup. btw: if you’re doing radiosity, make sure to add q3map_lightimage to all your terrain shaders, so they bounce the right color.
johnny_rocket> that goes away when you light anyway, doesn’t it?
ydnar> yeah
johnny_rocket> ok. otherwise, will they bounce the “common/terrain” image color?
ydnar> no, white.
johnny_rocket> white is default, ok
ydnar> yeah. the bsp doesn’t have common/terrain on the surfaces, or reference it whatsoever.
johnny_rocket> it just adds the surfaceparms to the surfaces? gtk feature request: hollower that automatically miters, and otherwise doesn’t create overlaps.
ydnar> uh, overlapping is fine. mitering of structural stuff is just a waste of time.
johnny_rocket> if you are in the inside of a hollowed room, then i agree.
johnny_rocket> super thanks to you for all your hard work on this
ydnar> np. been fun. btw, that’s a very angular map, no need for phong there. looks better with corners.
johnny_rocket> he he, you seem to get a real kick out of this stuff
ydnar> sure, i like making cool shit, or giving others tools to do so.
johnny_rocket> and improving something one of the top game companies made, that says a lot.
ydnar> just hacking. a14 soonish. vertex light fixes. couple other things. this one should do nearly-perfect vertex lighting.

jer> it was at 8 hours this morning before i left, and was on the final 9...
* +jer laughs
ydnar> your wolf vis?
jer> yeah.  last time i did a full vis it was only.  two hours, 45 minutes. its been a while.
ydnar> do you know why it’s taking so long?
jer> don’t know, ill see what vis looks like when i get home.
ydnar> you have a small blocksize.
jer> 256, yeah.
ydnar> which is creating tons of portals that can see each other, which is stupid. there is a better way.
jer> i have to try -merge with a small blocksize. haven’t yet though. the last time i did just -merge with the default blocksize, fogclip was useless.
ydnar> are you testing your map w/ and w/o fog to see how far it’s clipping at?
jer> yeah. i take the fog out and see where its clipping.
ydnar> he he
h0rst-ds> morning ydnar
ydnar> jerbearw0ou want the quick & dirty on how vis works?
ydnar> morning h0rst-ds
ydnar> jerbearw0ou also might want to consider using rr2d02’s q3map for vis, until i integrate his code.
jer> ah, didn’t know his was floating around. I’d be up for what ever testing i can help with. ydnar, can you turn off vertex shadows on terrain yet? q3map_novertexshadows doesn’t work i don’t think? or is that a goner?
ydnar> uh ... it should work. i don’t think i intentionally broke it, but vertex lighting for surfaces with lightmaps is calculated differently.
jer> i think i still have shadows from trees and structures. my terrain doesn’t have lightmaps-straight vertex.
ydnar> ok, then it’s getting traced per vertex.
jer> ill have definite answers when i get home-just going off memory from late last night

wiebo> light is bleeding between the wall and stairs. stairs are touching the wall.
jer> you can try to intersect the brush in to the wall maybe.
wiebo> i have a .map if you want to take a look ..... i did that.
jer> at work right now
wiebo> heh. i also made the stairs detail, as ydnar suggested. no dice.
wiebo> also, this never happened to me before with lighting a level.
jer> what version of q3map are you using?
wiebo> latest version
jer> q3map2 or from GTKRadiant 1.2.4 release?
wiebo> q3map2. the one from the gtk release crashed on me.
jer> i think it has to do with brush thickness-light tends to bleed with brushes thinner than 16 units, so here’s another idea: just to try.
wiebo> I’ll check brush size now.
jer> put some caulk underneath the stairs up against the wall. it will be invisible in game, but it might block the light
jer> the only other thing i can think of is reducing the lightmap sample size to get a more defined shadow
jer> but you might be able to accomplish the bleeding problem with caulk
wiebo> trying that now.....
jer> cool
wiebo> the stairs are 8 units thick. i hate new tools. ok, thickness was problem. i made the stairs 16 units high, and problem is gone.... thanks folks. weird though.
jer> word up
wiebo> still a bit of bleed at the steps though.... would scaling the lightmap work?
jer> probably. make the surrounding walls a func_group, and give them a _lightmapscale of 0.5. try that.
wiebo> hmm.... ok. that’s new for me.
jer> its a new feature.
wiebo> he he, obviously.

cloudscapes> oi, q about -bounce. do more passes mean brighter lightmap or more accurately lighted?
{wf}shadowspawn> bounce is radiosity. ok, think of a white room that is totally sealed up and no lights inside and you point a flashlight at the wall. the whole room will get lit from the light bouncing off of the spot where you are pointing the flashlight, right?
jer> basically
{wf}shadowspawn> so... it will make areas brighter.
jer> but that wouldn’t make the room fullbright. it makes the light more ‘realistic’ looking.
{wf}shadowspawn> yea which is a totally new thing to people used to the old q3map. yoda says you must unlearn what you have learned.
jer> heh, indeed
cloudscapes> heh, i should of made myself more clear. i know what radiosity is, but with every pass does it get brighter or more accurate?
{wf}shadowspawn> well brighter sort of. you know Photoshop? the airbrush tool?
cloudscapes> some radiosity renderers only get more accurate with every pass, not brighter, like cinema4d’s for example.
{wf}shadowspawn> think of it as ‘pressure’ and leaving it there.
cloudscapes> but others actually get brighter with every pass.
{wf}shadowspawn> yea, cause an area never lit before will become a light emitting shader for the next pass
cloudscapes> all this time I’ve been compiling these test maps thinking bigger bounce made the radiosity more accurate heh.
{wf}shadowspawn> but its not like infinite bounces will make it totally white.
cloudscapes> ahhh yeah. thx for the clarification, i wasn’t really sure. and here i was constantly changing the ambient lighting almost all the time, totally unconscious of the fact that i also kept changing the -bounce, lol, not thinking that it would affect brightness,
{wf}shadowspawn> yea ambient is more sensitive in some places. you get overbright areas if you aren’t careful
cloudscapes> yeah. overbright = i occasionally got radioactive blue water instead of the realistic look i was looking for
h0rst-ds> lo
{wf}shadowspawn> yea i got that too. heheh. but it looks kind of cool. *searches for a pic*
cloudscapes> now I’ll just leave -bounce at four all the time and leave the ambient as it is. it has some nifty effects sometimes, its true.
{wf}shadowspawn> http://www.shadowspawn.net/temp/shot0040.jpg that’s with ambient 12 and a slight bluish rgb, the water turned so bright. that’s an old pic though, like from a4. that water is only 8 units deep.
cloudscapes> whoa that’s a cool effect! you sort of got caustics near the center of the pic. i was getting the same kind of radioactive water, except on a terrain map, so i got weird artifacts.
{wf}shadowspawn> see i don’t have too much experience with terrain. i sort of do, i know that in the older q3maps the terrain looked totally different if you had a qer_editorimage for each 1to2 shader. i got so confused about that i gave up. belac has a lot of experience with it, i just ask him and he whips up a sample in like 2 seconds.
cloudscapes> I'm completely new to 1to2 type shaders and terrain. plus I'm not that good with shaders. nor am i good with lightmaps. ydnar is probably right that i shouldn’t have a lightmap less than 32, now that my terrain is almost fully textured it doesn’t show as much. examples work best, watch and learn.

monsto> y0h does a light ent’s fade key do anything?
ydnar> only on linear lights. fades out the attenuation, so a value of 0.5 makes the light spread over 2x the distance.

ydnar> backsplash point lights. you should use q3map_backsplash 0 0 in the shader to prevent the weird pools of light on those.