q3map_tcGen ivector ( 256 0 0 ) ( 0 256 0 )

johnny_rocket> i had two long compiles last night and today.. light fast -bounce 3 -bouncegrid -filter -shade -shadeangle 89 -thresh .5 -super 4 -patchshadows
ydnar> whoa
ydnar> how’d it look?
johnny_rocket> still, about 5 hours lighting, good for overnight
ydnar> he he
ydnar> yeah
ydnar> -super 4 + radiosity will do that
johnny_rocket> i looked fantastisuper smooth shadow
ydnar> there’s a point of diminishing returns with higher values for -super though
johnny_rocket> oh, and the texture alignment problem i was having. i added the same tcGen ivector to the normal shader for the stones and the normal brushes aligned with the terrain perfectly
ydnar> ahhh
ydnar> yeah
ydnar> good call

ydnar> use q3map_tcGen ivector ( 256 0 0 ) ( 0 256 0 )
ydnar> that will project the texture every 256 units in x, and every 256 units in y, along the z-axis .
jer> i take it that before the shader stages, right?
ydnar> yeah. or in your case, since you have a tcMod scale 0.0625, 64 / 0.0625 = 512
jer> yeah, they’re all 512x512 textures
ydnar> so use q3map_tcGen ivector ( 512 0 0 ) ( 0 512 0 ), or q3map_tcGen vector ( 0.0625 0 0 ) ( 0 0.0625 0 ), or q3map_texturesize 512 512, which ever

q3map_texturesize

_lightmapscale 0.5
q3map_shadeangle <angle> (in degrees) (specifies the breaking angle for phong shading)

ydnar> btw. -debugportals is a useful bsp switch. try it.
jer> indeed
ydnar> it’ll bsp the map with visible portals, so you can see exactly where vis can and cannot see
jer> I’m new to the vis stuff-never been a huge ‘pro mapper’ in the sense of optimizing what i work on
ydnar> well, now’s the time
Casey> is that basically the same as the portal viewer in gtk ?
ydnar> yeah, but it runs at 90fps =)
jer> its easier than ever
Casey> heh

ydnar> -thresh sets the recursive triangle subdivision threshold, default = 1.0

AF-haste> what is the “thresh” option?
ydnar> it recursively subdivides triangles to divine an origin and normal for a lightmap sample.
haste-haste> is there a shader option i can use to keep sharp shading when the angle between faces is less than shadeangle?
ydnar> don’t use -shadeangle <>. do it with shaders. I’m adding some more shit for that later on, like entity keys, etc, so you have a little more flexibility with that
haste-haste> func_groups and junk, great
ydnar> -thresh, btw makes phong shading smoother, because it averages more surface normals per luxel
haste-haste> what do different values do to it?
ydnar> -thresh 0.5 means every triangle is subdivided to 0.5 samplesize
haste-haste> 0.5 ?
ydnar> it’s like -extra for luxel mapping
haste-haste> 0.5 of what?
ydnar> it defaults to 1.0
haste-haste> well no wonder my compile is taking forever: -super 2 -thresh 0.5

ydnar> i spoke incorrectly, earlier. -samplesize is completely ignored in the -light phase

{wf}shadowspawn> wow that r_lightmap rocks
{wf}shadowspawn> you can see the shading for the phong

jer> q3map_novertexshadows. i have that on the terrain, and i still see shadows from the trees.
ydnar> q3map_novertexshadows, you can probably nuke that
jer> is that the same thing?
ydnar> dunno, i may ignore that now ;)

haste-haste> question do you subdivide? through the geometric center?
ydnar> i subdivide the longest edge recursively
haste-haste> are you still using barycentric coordinates for calculating normals?
ydnar> no, barycentric co-ords are shit with very long thin triangles, like those in patch bevel caps
haste-haste> makes sense
ydnar> so i ditched those for recursive subdivision. the lighting code was rewritten about a dozen times in the past month

jer> ydnar: q3map_subdivide still functional? worth keeping in?
ydnar>q3map_lightsubdivide is still necessary and good. patches usually have smaller lightmaps now lightmap allocation/projection code is all new and the patch size limitation is gone. patches can be as big as you want now

jer> ydnar: couldn’t find image for shader << is this still normal?
ydnar> yeah
jer> I’ve always gotten that... never understood why it says it
ydnar> it’s because there is no image associated with terrain shaders. they have no qer_editorimage or q3map_lightimage
jer> ah, that’s it
ydnar> which is why i added q3map_tcGen and q3map_texturesize
jer> yeah, using that now. texturesize.

Vexar> this message that 191 lights are culled always concerns me, how does it actually decide which light to ignore?

{wf}shadowspawn> this super is still hacking my brain. so super 3 is the same as extrawide then?
hro> what does -super do in a nutshell?
ydnar> -super is the generic replacement for -extra
{wf}shadowspawn> super 3 - 3 * 3 * 3? or 3 + 3 + 3
ydnar> i had been planning on adding -filter which will do a filtering pass across a lightmap to smooth it out, which would make -super 2 -filter the equivalent to -extrawide
{wf}shadowspawn> I’m just trying to figure out how much memory it takes now to do the same thing as extrawide did, in a nutshell
ydnar> extrawide didn’t take any more memory than -extra, it just did a crappy filtering pass. nobody at id ever used it because it’s broken.
{wf}shadowspawn> hey extrawide was the shit with shadows

ydnar> -super goes from 1 to infinity
ydnar> but nobody’s got the ram to do more than 16 or so
ydnar> though i suppose if someone did a 64-bit build of q3map it could work. but either way, -super is just a stopgap measure until -smooth is re-implemented

jer> ydnar: doing a _lightmapscale on worldspawn just makes more lightmaps?
ydnar> no. it scales the samplesize
jer> so instead of 128x128
ydnar> _lightmapscale 2.0 will make the samplesize for worldspawn brushes 32 instead of 16
jer> cause i went from 7 to 30? all 128x128
johnny_rocket> each lightmap is still 128x128
ydnar> um
jer> or is that correct?
ydnar> what value did you use?
jer> 0.25
ydnar> heh
jer> so it’d be every what... 4 units? or 8?
ydnar> that’s equivalent to samplesize 4
jer> yeah
ydnar> yeah. that should be taking 16x the lightmap space. but due to my 1337 (buggy) lightmap allocator, it don’t
jer> heh. digging it
ydnar> yeah. don’t use 0.25 for worldspawn
jer> those super nice shadows from last night
ydnar> put it on a func_group
jer> that was with func_groups @ 0.25
ydnar> with a few brushes you want to have nice shads
jer> but i did it to worldspawn, and didn’t get the same results
ydnar> uh
jer> understood-just some funky testing on my part

ydnar> _lightmapscale is a per-entity key that affects all brushes in that ent
ydnar> it’s taking the floating point full luxels and averaging them into the low-res storage luxels
ydnar> tcMod scale slows framerates on terrain maps
ydnar> new q3map allows you to directly specify texture projection for surfaces
ydnar> so you don’t need tcMod scale in-game
{wf}shadowspawn> friggin wow
jer> q3map_texturesize. love it
ydnar> yeah, q3map_texturesize is the other method. q3map_tcGen is the explicit method

ydnar> -meta is a bsp switch, not vis
h0rst-ds> what does it do ?
ydnar> makes a bsp more efficient by combining surfaces, removing coincident verts, & lowering the surface + vert count across the map
h0rst-ds> okay
ydnar> (higher fps)

pointy> can you explain in simple terms what the -meta switch does?
ydnar> oh yeah
ydnar> that could be a problem with surface merging
pointy> and is it bsp option?
ydnar> -meta is a bsp option that recomposes brush faces into their component triangles
ydnar> and reassembles them into larger contiguous surfaces
pointy> ta
ydnar> surfaces by default must be planar, but that can be overridden with the shader parm “q3map_nonplanar”
ydnar> “q3map_forcemeta” forces a surface to be atomized
ydnar> even w/o -meta
ydnar> -export is a base-level switch as well as an additional switch for -light
djbob> I’ll assume most of the efficiency loss is due to the 2nd lm not being full yet
ydnar> (-light -export will compute, then export
ydnar> -export/-import will just do their things

djbob> is debugsurfaces just first stage?
ydnar> no
djbob> light?
ydnar> -debugsurfaces on bsp phase generates a useless bsp
djbob> lol
ydnar> -debugsurfaces on -light just colors the lightmaps
ydnar> well, useless except for debugging
ydnar> done -debugportals at all?
ydnar> do that with your map
ydnar> make sure q3map.shader is in your scripts dir though

djbob> um
ydnar> ?
djbob> this thing is supposed to merge faces into surfaces, right?
ydnar> yeah
ydnar> with -meta
djbob> ah
djbob> only when you use -meta?
ydnar> yep
djbob> k
djbob> bsp stage?
ydnar> unless shader has q3map_forcemeta
ydnar> yeah, bsp phase
djbob> k

djbob> that’s better
djbob> got some gaps though, I’ll assume my textures are off for the moment
djbob> only merges planar?
ydnar> yeah
ydnar> and only to a max of 64 verts/surface
ydnar> which is the internal limit for mst_planar
ydnar> -debugportals?
djbob> in a min, in a min!
djbob> www.planetquake.com/toolz/shot0002.jpg
ydnar> 1337
ydnar> i knew you’d dig on -meta
ydnar> j0h
ydnar> do -patchmeta
ydnar> for kicks
djbob> god
djbob> wtf does that do?
ydnar> patches->mst_planars
djbob> merges a set lod into surface?
ydnar> yeah, subdivisions 8
djbob> might be fun
ydnar> sure
ydnar> planars get reduced nicely
ydnar> degenerate strips on patches have the bad triangles removed
jerbearw0rk> http://www.planetquake.com/toolz/shot0002.jpg << how do you read that exactly?
djbob> lol
jerbearw0rk> i am lacking the more advanced understanding knowledge of vis
ydnar> each contiguous block of color is a single drawsurface
jerbearw0rk> i know how to use caulk brushes to block shit
djbob> nothing to do with vis
ydnar> nothing to do with vis
jerbearw0rk> oh
ydnar> jinx
jerbearw0rk> har 8]
ydnar> basically
ydnar> the way djbob likes to map
ydnar> potentially produces lots of verts/lightmaps
jerbearw0rk> hmm
djbob> http://www.planetquake.com/toolz/shot0003.jpg
djbob> that’s without the hints
jerbearw0rk> looking at it i see a few selected key colors
ydnar> djb_fastsky 1 is a little better for debugportals
djbob> ah
djbob> yeah
jerbearw0rk> is that for the number of lightmaps, and what lightmaps have what surfaces?
djbob> was thinking there must be a way to have a darker color
ydnar> djb see the fanned stuff
ydnar> which, btw, you should fix, because fanning creates verts
ydnar> ;)
djbob> i know..
jerbearw0rk> harumph.
djbob> http://www.planetquake.com/toolz/shot0004.jpg
jerbearw0rk> each contiguous block of color is a single drawsurface << so if your floor gets chopped up in to a bunch of polygons, each poly would be colored?
djbob> now for with hints...
djbob> this should be fun
ydnar> he he
djbob> eek
ydnar> djbob finding this useful?
djbob> rainbow!
djbob> not really useful
djbob> i already know how to place hint
ydnar> yeh
djbob> and surfaces, well it’ll be nice to confirm, i guess
ydnar> how many redundant indexes in that map, anyway?
djbob> hmm?
ydnar> when you bsp it
ydnar> it says how many redundant indexes were suppressed
djbob> never checked
ydnar> each surface no longer gets it’s own index pool
ydnar> it checks for identical runs of ints already stored
djbob> ah
ydnar> and reuses the djbob> kewl
ydnar> saves 200-400k on large maps
djbob> http://www.planetquake.com/toolz/shot0005.jpg
djbob> bwahahaha
ydnar> you dipshit
jerbearw0rk> good lord
ydnar> ;p
djbob> o_o
ydnar> you dipshit
ydnar> honestly
djbob> hmm?
ydnar> that is totally unnecessary
djbob> lol
ydnar> Chris
ydnar> haha
djbob> i went a little overboard, yeah ;)
djbob> only 80k vis so bleh
jerbearw0rk> i fail to understand how to decipher that...
ydnar> yeh
jerbearw0rk> so many colors... its like fear and loathing
ydnar> i notice a lot of portals in solid areas
djbob> uh
djbob> solid?
ydnar> like inside the crook of that u hallway
djbob> lower left?
ydnar> y
djbob> uh, that’s a big rectangular room
ydnar> ah
djbob> it’s not a hallway
ydnar> lol
ydnar> that’s pretty nuts
djbob> hmmm?
ydnar> careful what you save in visdata you’re not making back in leafsurfaces and leaves
djbob> well, i had exactly the same hint splits, and had 150k vis
ydnar> and then?
djbob> cut it down, by removing redundant ones they were creating
djbob> basically, extended a lot of them way out of the map
jerbearw0rk> blam. is that the image that deals with vis?
djbob> i could really do with a skip shader
jerbearw0rk> crazy colors in space instead of painted on surfaces
ydnar> heh
djbob> or...
djbob> hinting planes
ydnar> that’s why you align the other faces of a hint brush with existing structural planes
djbob> what’s the point though? they ain’t useful to the map?
ydnar> that’s the same as making them skip
ydnar> brb
djbob> they use up space in the bsp for no reason
djbob> there, down to 46k
ydnar > sweet
ydnar> got dm7 from 20 lightmaps -> 1 jerbearw0rk> nice
jerbearw0rk> djb enlighten me-doing the vis tweaking you do to bring vis data size down, does that do anything other than just free space from the bsp? do you actually optimize the vis set when you do those tweaks?
djbob> the original hinting improved the vis
djbob> the stuff I’m doing now, is just removing a lot of the clutter my sloppy hinting did
jerbearw0rk> and that makes the vis lump smaller while being effective?
djbob> yes
* +jerbearw0rk nods
djbob> and improves the vis’ing time
jerbearw0rk> time for vis compile that is
jerbearw0rk> neat
djbob> + I’ll have less leafs => game should run a tiny bit faster
djbob> 32k
djbob> 19sec vis, not bad
djbob> 37k... hmm
ydnar> lol
ydnar> oh yeah, vlight dies
djbob> didn’t plan on using it
ydnar> lol
ydnar> very very broken
ydnar> will get ttimo to make a new dir in cvs
ydnar> q3map2
ydnar> because i don’t really care to make vlight work
djbob> what use is it now anyway
djbob> ?
ydnar> yeah
ydnar> not much
ydnar> -light fast is as fast in most cases anyway
ydnar> it does have one thing better though, that is nicer anti-aliasing
ydnar> but i was planning on making yilluminateluxels() use hybrid light volumes/tracing algorithm anyway
ydnar> at which point i really kill vlight
ydnar> i wonder if Vexar is still using fast
ydnar> 7 hours -> 10 mins wasn’t bad
djbob> lol

djbob> btw ydnar
djbob> patchmeta
djbob> is p00p
ydnar> no shit
{wf}shadowspawn> heheh
ydnar> gah
djbob> fine for a circle
djbob> but inverted....
ydnar> <- rewriting initial lightmap dole again
ydnar> bad things happen?
djbob> texture co-ords screwed
ydnar> ah yeah.
ydnar> -patchmeta is sort of like a vestigial organ
ydnar> not terribly useful except for certain things
djbob> hmm
ydnar> may change it to automatically do it on rectangular or triangular patches though

ydnar> -filter should make your shadows look nice
]s[belac> that replaces smooth?
ydnar> djb need to make a couple more alterations to the lightmap code
ydnar> so two metasurfaces that are coplanar and touching will use the same lightmap
djbob> what to do?
djbob> k
ydnar> that way no matter how complex a floor is it’ll be merged into a single clean lightmap.
ydnar> no weird edge case
djbob> what if the surface is really big
ydnar> also, you may notice that lightmaps are biased to z axis projection
ydnar> before z-axis was last choice
djbob> nope, cant say i have
ydnar> so if a surface is upwards facing at least 45 degrees
ydnar> (or down)
ydnar> it’ll get a z-axis lightmap projection
jerbearw0rk> nice

ydnar> q3map_bounce 0.0
ydnar> in the shader, or any fraction
]s[belac> will that speed things up?
ydnar> sure
]s[belac> 1 is default?
ydnar> yeah
ydnar> 1.0 is default