Lightmapped Terrain: The quick and dirty Q3Map 2.0.x how-to

Lightmapped terrain is a hack, and as such, has limitations. It cannot be environment mapped, or have any effect that requires a surface normal. Such is life unless id makes a pr to support it.
Before you make any terrain with q3map 2.0.x or higher, your terrain shaders (typically textures/common/terrain and terrain2) must have the “q3map_terrain” keyword. Terrain is handled completely differently than from previous versions of q3map, and as such, it doesn’t have any built-in shader name mangling for terrain entities.

The terrain shader must be listed in shaderlist.txt or this will not work.

Use the following crib sheet to convert a typical terrain shader into lightmapped terra
// old-style vertex lit terrain shader

textures/terrain/hillside_0
{
q3map_forcesunlight
q3map_novertexshadows
surfaceparm nolightmap

{
map textures/terrain/hillside_0.tga
tcMod scale 0.05 0.05
rgbGen vertex
}
}

// Lightmapped terrain shader

textures/terrain/hillside_0
{
q3map_lightmapsamplesize 64
q3map_lightmapaxis z
q3map_texturesize 256 256
q3map_tcGen ivector ( 256 0 0 ) ( 0 256 0 )

{
map textures/terrain/hillside_0.tga
}
{
map $lightmap
blendFunc gl_dst_color gl_zero
}
}

// Lightmapped terrain shader for blending between two layers

textures/terrain/hillside_0to1
{
q3map_lightmapsamplesize 64
q3map_lightmapaxis z
q3map_texturesize 256 256
q3map_tcGen ivector ( 256 0 0 ) ( 0 256 0 )

{
map textures/terrain/hillside_0.tga
}
{
map textures/terrain/hillside_1.tga
blendFunc gl_src_alpha gl_one_minus_src_alpha
alphaGen vertex
}
{
map $lightmap
blendFunc gl_dst_color gl_zero
}
}

Never went terribly out of my way to point this out to anyone, but terrain in Q3Map2 has a couple nifty features:
- It can be made of mixed brush faces and patches.
- You don't have to use a "terrain" func_group at all. In fact, "terrain" "1" isn't even looked at. The terrain code is nothing more than shader substitution based on an indexmap (alphamap).

So given these two facts, you can move all your terrain brushes to worldspawn, and add the following keys to the worldspawn entity:
_indexmap (was alphamap)
_layers (was layers)
_shader (was shader)

If you mix patches in with your terrain brushes, textured with common/terrain (or whatever), then it will blend and light right along with the rest of the terrain just fine. Even the texturing will work.

y

Make double sure any shaders you're using that don't have a lightmap have a surfaceparm nolightmap. You may be lightmapping the sky and not knowing it.

y

If you use -filter (or -extrawide, which is equivalent to -super 2 -filter), then your mileage may vary on lightmapped terrain. The problem is that the filtering algorithm only looks at a single lightmap when filtering. This is OK with normal adjacent brush faces lying in the same plane because they will usually be on the same lightmap. However, lightmapped terrain is a special case of non-planar lightmap projection, and thus suffers from all the potential weirdness that np projection brings with it. Adjacent meshes will not be put into a seamless lightmap. This is to avoid erroneous lightmap projection on cyclical-overlapped cases.

An example would be a continuous mesh of a spiral ramp. Higher portions of the ramp would shadow lower portions of the ramp, giving improper shadowing.

I hope this sort of makes sense. It was something I wrestled with a while ago for a couple weeks trying to get right. When I have time and access to my development machine, I plan on revisiting this problem.
In the meantime, you can work around it by adjusting the terrain a bit (including the indexmap/alphamap) and/or omitting -filter from the lighting phase.

y

With lightmapped terrain, -filter one must use not. </yoda>. See, -filter applies a 3x3 box filter (similar to Photoshop's blur) to the lightmap. It breaks down on the edges of a lightmap because there isn't anything to sample from off the edge. This is what's causing the noticeable edges in your lighting.

y

ydnar> terrain faces are just normal brush faces now. But if you have a terrain face inside of a structural brush, it’ll get chopped and t-junctioned.
AF-haste> it’ll get chopped, cool.
ydnar> terrain doesn’t have to be an ordered grid either
haste-haste> sweet, easier to kill sparklies on terrain maps then
jer> ydnar means i could use decimation in gensurf?
ydnar> sure
haste-haste> wow
ydnar> but be careful. The indexmap (what the alphamap is now called) could get screwed. terrain” “1” isn’t necessary anymore.
ydnar> any ent can have an alphamap, specified with “_indexmap” or “alphamap” keys. And “_shader” instead of “shader”, “_layers” instead of “layers” etc
jer> dig it
ydnar> next couple of weeks I’ll explain how to do lightmapped terrain
haste-haste> and I’ll be able to replace those silly patches I’ve been using for sand.
jer> ydnar, what should terrain vis blockers use for a shader? Sky brushes?
ydnar> haste-haste: terrain can be made of patches, too.
ydnar> structural caulk brushes. and good hinting.
jer> right. The caulk should be underneath the terrain surfaces then, as to not remove them
ydnar> let me get this new build out that should fix the phantom light problem

ydnar> terrain gets chopped now. So if it’s in a solid, it’ll get nuked. No more special case paths for it.
ydnar> the terrain is no longer this “special” shit anymore. It’s normal brush faces like everything else, except it passes through the metasurface pipeline. Therefore, unlike before, structural brushes will chop up terrain. The entire terrain pipeline is new code i wrote yesterday, borrowing bits from dose’s original terrain.c file.

ydnar> “snowterrain”?
ydnar> hmm
ydnar> that’s a shader of yours, right?
pointy> it’s the same as terrain but has surfaceparm snowsteps
ydnar> ok
ydnar> that’s going to be useless now
ydnar> you’ll need the snowsteps surfaceparm in the individual shaders
ydnar> but then again, you can have rocksteps on the rock layers
pointy> so i have to redo all the terrain?
ydnar> no! just the bleeding shaders. and change your entity to use common/terrain.
pointy> that snowterrain did not have a surfaceparm nolightmap
ydnar> yeah, add surfaceparm pointlight or surfaceparm nolightmap to those
johnny_rocket> do you need to use -meta for the lightmaps to work properly on terrain?
ydnar> no, you need it if you want decent r_speeds with certain maps

ydnar> remove rgbGen vertex from all your shader stages
ydnar> the blend stages must have alphaGen vertex
]s[belac> just -lightfast didn’t fixed, trying now with out -meta
ydnar> and the last pass is { map $lightmap /// blendFunc gl_dst_color gl_zero }
ydnar> but I’d seriously consider adding q3map_lightmapsamplesize 64 to all your terrain shaders if you insist on doing this
ydnar> or add a _lightmapscale to the terrain entity with a value of 3 or 4 or higher
pointy> i tried _lightmapscale
ydnar> keep in mind that some weird shit could potentially happen, as i don’t “officially” support lightmapped terrain yet
pointy> all blends have alphaGen vertex
pointy> is it something to do with forcesunlight?
ydnar> yeah, nuke that
]s[belac> no that’s to blend it with other textures
ydnar> and the novertexshadows crap
ydnar> you want the blend stages to get the alphaGen vertex to blend
pointy> one sec let me upload the shader
ydnar> but if you want a lightmap to show up, you need to add the lightmap to it
ydnar> {
ydnar> map $lightmap
ydnar> blendFunc gl_dst_color gl_zero
ydnar> }
ydnar> ok
ydnar> nuke the shitty tcMod scale
ydnar> replace with q3map_tcGen ivector

pointy> anyone know how i box map my terrain?
cloudscapes_work> i think ydnar has an example on his site, on tcGen
cloudscapes_work> x, y and z mapped individually in his example terrain
pointy> thx looking now

ydnar> re sn
dog-sweetnutz> heyya man. loving this terrain lightmap stuff
ydnar> it’s working out well for you?
dog-sweetnutz> yeah quick compiles too. rather amazing.
ydnar> nice
dog-sweetnutz> made the lightsample size a bit smaller, figured out a trade-off between bsp size/load time and shadow detail
ydnar> lmt.txt was clear enough?
dog-sweetnutz> yea, only thing i didn’t get at first was to add q3map_terrain to the common/terrain shader
dog-sweetnutz> took me a sec, was adding it to mine then i noticed common
ydnar> any shots?
dog-sweetnutz> still compiling, in a few mins
ydnar> k
ydnar> alphashadows looks nice
dog-sweetnutz> need twenty-seven to fix the snow so i can have falling snow, and then fix up the third tree model
dog-sweetnutz> yea
ydnar> btw
dog-sweetnutz> what’s up
ydnar> if you have any caulk brushes extending up out of the terrain, get rid of them
dog-sweetnutz> alright, don’t think i have any right now. i think I’m getting some shadows up top because the sky is a little low
ydnar> the terrain in the distance in that shot looks a wee dark
ydnar> ah
ydnar> yeah, the sky/sun code is new in 2.0
dog-sweetnutz> ahhh ok. I’m going to try raising the sky some
ydnar> what’s your sky shader?
dog-sweetnutz> textures/sweetnutz2/sn_snowterr_sky
dog-sweetnutz> {
dog-sweetnutz> qer_editorimage textures/sweetnutz/sn_snowterr_sky.tga
dog-sweetnutz> surfaceparm noimpact
dog-sweetnutz> surfaceparm nolightmap
dog-sweetnutz> q3map_globaltexture
dog-sweetnutz> q3map_lightsubdivide 1024
dog-sweetnutz> q3map_surfacelight 140
dog-sweetnutz> skyparms env/snowterr/arcn 256 -
dog-sweetnutz> }
ydnar> ok. might want to make it a tad brighter
dog-sweetnutz> also i do have some brushes inside the terrain for vis blocking that extend upwards
ydnar> well, 140 should be ok
dog-sweetnutz> yea
dog-sweetnutz> i don’t have any bounce
ydnar> using -light fast?
dog-sweetnutz> i might try that
ydnar> yeah
ydnar> lose any and all caulk brushes that extend up out of the terrain
ydnar> and clip your terrain to the buildings
dog-sweetnutz> clipped to buildings. the brushes that extend out are textured with sky
ydnar> yeah, not good
dog-sweetnutz> to block visibility
ydnar> better to hint
dog-sweetnutz> well either that or r speeds of 15k
ydnar> and put axial caulk brushes inside the hills
dog-sweetnutz> I’ve got axial caulk inside the hills, so the part that extends upward i can use hint instead eh
dog-sweetnutz> ill try that
ydnar> no, i mean use a horizontal hint, and increase blocksize. worldspawn key “_blocksize”. set it to 2048 or 4096
dog-sweetnutz> alright. ah wait i did raise blocksize to 2048. need to learn more about hint brushes, I’ve read a few things on it, but the concept still gets me, ydnar
ydnar> well, since terrain is lightmapped, having structural brushes extend through the terrain leads to occluded samples & wonky lighting
dog-sweetnutz> yeah i noticed that. i just thought I’d play with bounce to minimize it since i need to block vis to certain sections of the map
ydnar> bounce won’t fix it
dog-sweetnutz> ah, crappy
ydnar> you can do good vis without putting blocks through terrain
dog-sweetnutz> ah. going to go read one of those hint brush links again on the forums

jer> what’s the deal with surfaceparm pointlight on terrain? is that something i should put in?
ydnar> i made it equivalent to surfaceparm nolightmap
jer> what does q3map_lightsubdivide do again?
ydnar> chops up surfaces
jer> the higher the number, the lower the number, etc?
ydnar> in lighting phase
ydnar> into more, smaller lights
jer> ah, okay
jer> i see the mp_beach sky has 2048
jer> what’s q3map_globaltexture do?
{wf}shadowspawn> um
{wf}shadowspawn> shader manual, i forgot myself, except it somehow keeps things from tiling
{wf}shadowspawn> used during tcMod

ydnar> ok
ydnar> do you have a tcMod scale on there?
johnny_rocket> nope
ydnar> so each terrain shader has an image?
johnny_rocket> wait
johnny_rocket> sorry, a definite yes on the tcMod
ydnar> ok. nuke that shit. replace it with a q3map_tcGen ivector ( 256 0 0 ) ( 0 256 0 )
ydnar> that will repeat the texture every 256 units in x and y
ydnar> (the q3map_tcGen ivector goes up at the top of the shader, not on a stage, btw)
johnny_rocket> ok. right
ydnar> and nuke the tcMod scale. can you msg me the shaders you’re using?
!]s[belac> not on a stage? so my terrain is done wrong?
ydnar> lol. yeah. q3map_* goes at the head of shaders
!]s[belac> oh wait. what’s the diff?
ydnar> i tried to make it work like before with existing terrain shaders, but i don’t think that’s going to be entirely possible
!]s[belac> between that and tcGen vector ( .001953125 0 0 ) ( 0 .001953125 0 )?
ydnar> q3map_tcGen * does texture coordinate generation in q3map
ydnar> oh
ydnar> q3map_tcGen vector and q3map_tcGen ivector are the two supported methods
ydnar> ivector = inverse vector, easier to read
ydnar> vector is ( 1/units 1/units 1/units ) form
ydnar> rather than ( units units units ) form
!]s[belac> ok so those are new huh?
ydnar> yeah, added those
!]s[belac> nice

ydnar> jetscreamer
jetscreamer> yo
ydnar> your terrain brushes should go all the way to the base
jetscreamer> they do
ydnar> who was posting on q3w about thin terrain brushes?
jetscreamer> me
ydnar> that’s really dodgy
jetscreamer> that’s how ezgen generated it
ydnar> it’ll increase the map planes by a factor of two
jetscreamer> spaced i mean
jetscreamer> wait I’m dum. are you saying don’t use the thin mesh?
ydnar> yes
ydnar> thin mesh = bad
jetscreamer> compiles faster, but ok
ydnar> what compiles faster?
jetscreamer> thin mesh does
ydnar> yeah
ydnar> patches are nonsolid when turned into triangle soup
jetscreamer> in light it’s most noticeable
ydnar> really
jetscreamer> but that was before this alpha
ydnar> with 2.0.0 or 1.2.x?
jetscreamer> 1.2.4 or so
ydnar> ah
ydnar> you know what though
ydnar> you should make the sky brushes as fitted to the outside edge of the terrain as possible
ydnar> don’t have empty space below the terrain that’s textured with sky
jer> snapping your terrain to a grid of 8 is a big help
ydnar> since 2.0.x, it’s better to have your terrain brushes go all the way down

ydnar> {wf}shadowspawn that clipwinding error is because i haven’t changed the surface light code to take into account merged meta surfaces yet
{wf}shadowspawn> oh ok
ydnar> i can fix it
ydnar> but backsplash lights will look funny

ydnar> pointy you may want to add q3map_globaltexture to your terrain shaders, and see if that fixes it
ydnar> you did change your terrain shaders to use q3map_tcGen ivector or q3map_texuresize right?
]s[belac> something is giving off light like its supposed to
]s[belac> err is not
ydnar> ]s[belac surface light code is undefined for metasurfaces
ydnar> because i haven’t modified the code that creates surface lights to deal with the metasurfaces yet.
]s[belac> ah
ydnar> because i haven’t found a decent solution for the backsplash issue.
ydnar> backsplash works fine on convex polygons, but fails miserably on the larger metasurfaces that q3map now creates.
ydnar> because there is no good “center point” with which to place the backsplash light
ydnar> backsplash is shitty anyway, and I’d prefer to get rid of it. people would bitch too much though.
]s[belac> yah, i don’t like backsplash much either, looks stupid
ydnar> ok
ydnar> everyone add the following string to your common.shader file
ydnar> in common/terrain and common/terrain2
ydnar> “q3map_terrain”
cloudscapes_work> i didn’t name it terrain easygen did
cloudscapes_work> do i just comment out surfaceparm nolightmap there?
ydnar> uh
ydnar> that will have q3map generate lightmaps on the terrain
ydnar> you have to do some other adjustments to the shaders in order to make it work properly
ydnar> which i don’t have time to explain at the moment
cloudscapes_work> okay
cloudscapes_work> thx for the help so far
ydnar> I’ll release a terrain demo map with lightmapped terrain at some point
ydnar> it’s kind of involved to get working correctly
cloudscapes_work> cool !

pointy> just want to ask a quickie
pointy> what does q3map_tcGen ivector (24 0 0) (0 24 0) do?
pointy> i did the terrain shader and got a lightmap showing
pointy> how do i scale the textures?
jer> http://particle.mindgrid.net/wolfmp/dev/fogclip/
jer> pointy q3map_texturesize [x] [y]
jer> use that in your terrain stages
pointy> ok thx
pointy> what does this line do? q3map_tcGen ivector
jer> that is the same
jer> just more precision
ydnar> q3map_tcGen ivector is better than q3map_texturesize
ydnar> lets you have exact control over how a layer is projected onto the terrain surface
pointy> didn’t seem to have any effect here
jer> you’d have 2 vectors, q3map_tcGen method> (x y z) (x y z)
ydnar> so you could, in theory, have a layer that was projected along the x-axis, rather than the default z-axis
pointy> yes that is what i have
ydnar> for sides of cliffs and shit
ydnar> ok
ydnar> how big are your terrain textures?
pointy> but when i changed the numbers nothing changed
jer> you have to recompile
jer> for the changes to take effect
jer> they are written in to the bsp
jer> oh pointy> i did
ydnar> pointy you want your terrain textures to repeat every 512 units?
pointy> textures are 256x256
ydnar> ok
ydnar> every 256 units?
jer> they’ll repeat a lot
ydnar> fine
jer> stretching it x 1.5 or 2 is good
jer> that’s the math i use
ydnar> q3map_tcGen ivector ( 256 0 0 ) ( 0 256 0 )
pointy> old shader had tcMod scale 0.041666668 0.041666668
ydnar> yeah
ydnar> that’s because w/o an image, q3map thought the texture was 64x64
pointy> let me try that
ydnar> which is why ta terrain typically has the tcMod scale
ydnar> which slows it down a lot
ydnar> btw
ydnar> that parm goes at the top of each shader
ydnar> not per stage
jer> using bad terminology
pointy> yes
ydnar> post your shader when you’re done so i can take a look
pointy> textures/schwalbe_terrain/terrain_0
pointy> {
pointy> surfaceparm snowsteps
pointy> surfaceparm nolightmap
pointy> surfaceparm pointlight
pointy> q3map_tcGen ivector (256 0 0) (0 256 0)
pointy> {
pointy> map textures/turbopoint_terrain/s_dirt_m03i_2.jpg
pointy> }
pointy> {
pointy> map $lightmap
pointy> blendFunc filter
pointy> }
pointy> }
pointy> that’s 1st bit
pointy> hmmm
pointy> i must be missing the plot here
pointy> it’s still the same
johnny_rocket> hiyas
pointy> do i need any compile switches?
jer> what version of q3map2 are you using?
johnny_rocket> should you take out nolightmap and pointlight? won’t that conflict with the lightmaps?
pointy> a9
jer> cool
pointy> the textures is still very small
jer> q3map_tcGen ivector (512 0 0) (0 512 0)
jer> that will double their size
pointy> hmmm
jer> try 768 in place of 512 if they are still too small
jer> try those
pointy> they are not changing at all
jer> those even
jer> you have q3map_tcGen ivector (256 0 0) (0 256 0) before every stages for each shader?
pointy> no dif from when it was 24 to now 256
pointy> yes
johnny_rocket> do you have another shader (e.g. a backup) that might be conflicting?
pointy> no i renamed it
pointy> i just checked
johnny_rocket> and you renamed the shader in the terrain entity? I’m sure you did but worth the question
pointy> yes
jer> don’t call the terrain terrain
jer> call it something else
jer> it’s a keyword that sets certain flags
jer> rename it textures/schwalbe_terrain/do_*
pointy> done
jer> and of course, change the shader keyword in your func_group
jer> give that a whirl
jer> you may want to change the 256 value to 512 -- the textures will be very repetitive at their native sizes
jer> that is, in the tcGen ivector line
jer> but one thing at a time
jer> especially with small textures
ydnar> nooo
pointy> well it still looks the same to me

{wf}shadowspawn> someone was asking about fog a while back, if its possible to do volumetric lighting on it. is that just fantasy?
{wf}shadowspawn> while I’m on bounce 2! heheh
* ydnar rolls his eyes
{wf}shadowspawn> heheh
ydnar> btw
ydnar> fog should cut terrain now
{wf}shadowspawn> cut?
ydnar> yeah
ydnar> ever done fog with terrain?
ydnar> it looks like shit because it doesn’t clip the tris
{wf}shadowspawn> yea but
{wf}shadowspawn> yea
ydnar> well, it should now

ydnar> here’s what q3map_terrain sets
ydnar> q3map_indexed
ydnar> q3map_nonplanar
ydnar> forces -meta on it
ydnar> q3map_shadeangle 179
ydnar> q3map_lightmapaxis z
cardigan> should i take nolightmap out of common/terrain too or is that automatic?
ydnar> cardigan: doesn’t matter
ydnar> it’s an “indexed” shader
ydnar> which means it references an _indexmap (alphamap)
cardigan> ok - what about the terrain shaders? do i need to remove rgbGen vertex?
ydnar> lightmapped terrain is totally experimental
ydnar> I’d add a _lightmapscale 4.0 to your terrain ent
cardigan> _lightmapscale goes in common/terrain rather than the metashader?
ydnar> noononono
ydnar> _lightmapscale is an entity key
ydnar> you could alternatively add q3map_lightmapsamplesize 64 (or something) to the terrain metashaders
ydnar> you don’t need alphaGen vertex on stage 0 of blend shaders
ydnar> all that does is grab the vertex alpha which is never used by that stage
ydnar> and get rid of the nolightmap/pointlight stuff

ydnar> pointy add a _lightmapscale key to your terrain entity
ydnar> 2.0 or 4.0
pointy> k
pointy> u said i could lose the alphaGen vertex
pointy> {
pointy> map textures/turbopoint_terrain/s_dirt_m03i_2.jpg
pointy> alphaGen vertex
pointy> }
pointy> from this part?
ydnar> yeah
ydnar> that stage is getting a blend of gl_one gl_zero by default (no blendFunc) which means it’s just wasting cpu copying the vertex alpha
ydnar> your blend shaders have three stages, ok?
ydnar> texture 0, texture 1 (with alphaGen vertex + blendFunc blend), then lightmap. so none of the texture 0 stages need an alphaGen vertex
pointy> ok i meant in 0to1 - 3to4
ydnar> yes

jer> hrmph
ydnar> ?
jer> well
jer> on ‘normal
jer> err
jer> ‘normal’ terrain
jer> i have q3map_terrain in common/terrain
jer> and the texture image is like, super tiny
jer> q3map_texturesize 768 768
jer> and its probably like 64 x 64
jer> its an unlit map though
jer> didn’t think that’d make a diff?
jer> metashader example
jer> spam>
jer> textures/mindgrid_terrain/motherofgod_0
jer> {
jer> surfaceparm grasssteps
jer> surfaceparm nolightmap
jer> surfaceparm pointlight
jer> q3map_novertexshadows
jer> q3map_forcesunlight
jer> q3map_texturesize 768 768
jer> qer_editorimage textures/mindgrid_terrain/terrain_00_grass.tga
jer> {
jer> map textures/mindgrid_terrain/terrain_00_grass.tga
jer> rgbGen vertex
jer> }
jer> }/spam>
jer> did that come through alright ydnar> uh
jer> should i also have q3map_tcGen ivector? isn’t that redundant?
ydnar> are you doing lightmapped terrain?
jer> no
jer> that’s the thing
jer> not interested in that yet
ydnar> pointlight/nolightmap mean the same thing
ydnar> q3map_texturesize 768 768 is fine
ydnar> if you want any shadows at all, you need to remove the novertexshadows and forcesunlight
ydnar> btw
ydnar> is the shader in shaderlist.txt
jer> of course
ydnar> do you have a tcMod scale?
jer> nope
ydnar> post your shader
jer> q3map_texturesize 768 768
jer> in the dir now
jer> straight plain old terrain
jer> common.shader common/terrain has q3map_terrain
ydnar> and that’s the terrain you’re using?
jer> affirmative
ydnar> that is wacky
jer> isn’t it
jer> is q3map_terrain required?
ydnar> well, it seems to be blending right
jer> yeah, blends are fine
ydnar> q3map_terrain only on the common/terrain shader
jer> 8 layers and all
jer> yeah, that’s what I’ve got
ydnar> hmm
ydnar> maybe something broke texturesize
jer> only diff between this compile was common/terrain and a11
jer> before that, everything was cool
ydnar> what version were you using before?
jer> a9
ydnar> ok
jer> a10 i had invisible terrain?
ydnar> a10 introduced common/terrain
ydnar> invisible terrain?
jer> yes
jer> no q3map_terrain
ydnar> heh
jer> (before you posted the text)
jer> no tris even
ydnar> yeah
jer> but clipped
ydnar> let me try texturesize here
jer> i thought it was my giant hint brush at first, but then lmt.txt made sense
jer> mmmkay
ydnar> q3map_texturesize is really for times when you want to have a small lightimage but want the texture to map as if it is bigger
jer> its just easy to read, understand, and modify for m jer> x and y baby
jer> but i can try the other
jer> ivector happy happy

jer> anyone want to talk about hinting while i wait for this compile?
jer> http://particle.mindgrid.net/wolfmp/dev/hinting/terrain_hinting.gif
jer> I’m tying to figure out how to hint for not rendering the other half of a ‘mountain’ in that pic
jer> i think i understand that hint brushes create portals where their faces are ‘visible’ (not against a structural surface)
jer> and the volume of the brush isn’t what they’re used for
johnny> yeah, just the sides of the brush
jer> which... brush?
ydnar> yeah, hint brushes create portals
jer> so a cube in the middle of nowhere would create a cube of 6 portals
johnny> potential
jer> fair enough
johnny> for your mountain, one technique would be to have a sky brush meet the top of your caulk brush to help prevent the other side of the mountain from being drawn
jer> but with the new q3map, would that remove the faces of terrain where it touches it?
jer> it would chop off the top triangle of terrain starting at the flat top caulk side
jer> (trying to get a grasp with how the new compiler will work)
jer> before q3map2, i had caulk walls going from bottom to top of the box to block vis
{wf}shadowphong> wasn’t there something in the terrain manual about a large hint perp to the floor/sky that stretched across everything
{wf}shadowphong> err parallel
{wf}shadowphong> yea under the ‘other tips’ part
{wf}shadowphong> horizontal hint brush at a point about midway up the slopes of the terrain
{wf}shadowphong> err terrain
{wf}shadowphong> i tried that once and it took forever and a day to compile vis even though the visdata size was small
jer> a height where players would never get to, obviously
{wf}shadowphong> midway up the slope
{wf}shadowphong> horizontal
{wf}shadowphong> dunno how that would fit in with some of these canal pics I’m seeing in there though
{wf}shadowphong> terrain is cool but games like tribes2 or any mod with a grapple... that’s why i only ever played with it
jer> I’m trying to do a large war map for wolf
jer> it will have low frames with high detail, but competitive players crank down the detail to get high frames regardless
{wf}shadowphong> yea everyone is stuck on the ground so you can play heh
jer> compile done, brb
{wf}shadowphong> oh ydnar
{wf}shadowphong> yes i did check
{wf}shadowphong> and its like patches on top of caulk
{wf}shadowphong> where the patches meet the brushes
{wf}shadowphong> or just joints
{wf}shadowphong> didn’t try 12 though I’ll check
johnny> he he, nice nick shadow
{wf}shadowphong> I’m going to get this phong down if i pass out at my keyboard trying
ydnar> btw
ydnar> if you want to hint large terrain maps
ydnar> you have to set the blocksize very large
ydnar> to something like 16384
ydnar> or 32768
ydnar> shots?
ydnar> {wf}shadowphong: are there other surfaces visible behind the patches?
ydnar> keep in mind that q3map doesn’t t-junction patches
{wf}shadowphong> no. straight joints
{wf}shadowphong> like two brushes side by side equal widths
{wf}shadowphong> right between “em
{wf}shadowphong> and where patches meet wall, like a curved floor like sand would appear
{wf}shadowphong> everything on the grid too, like a 32 unit grid and nothing obscene
{wf}shadowphong> but let me try 12
johnny> {wf}shadowphong read wired magazine at all?
{wf}shadowphong> yes as a matter of fact last issue is in my car, i was reading it in traffic
{wf}shadowphong> bad traffic
jer> back
jer> ydnar: i have texture weirdness in terms of small scale for some reason
jer> have shots, one sec
johnny> heh, read it today on the train and thought you might like the article about ai
jer> same shader that you reviewed last time too
ydnar> oh shit
ydnar> i never fixed the texturesize bug for terrain
{wf}shadowphong> heh
{wf}shadowphong> hm
jer> forgive the texturesize
jer> green line is where I’m trying to block vis-from either side, don’t draw the other (unless you’re near the opening)
jer> green line in the hint_shot0019.jpg
jer> that is
ydnar> set blocksize to 32768
ydnar> then make a large hint that splits the world vertically
ydnar> above player space
jer> where do i set blocksize, q3map -vis?
ydnar> no
ydnar> _blocksize key in worldspawn
jer> ah
* +jer nods
jer> i take it that its units, right?
ydnar> and make sure there is an axial caulk brush inside that hill
ydnar> yup
jer> the map is like, 16384x5632 or something
ydnar> yeah
jer> there is a caulk brush in there
jer> you think 16384 is okay then, or should i just throw in the 32768
ydnar> 32768
* +jer puts the beer down
ydnar> to stop the blocksize
jer> heh, mmmkay
ydnar> then you need two hints that go diagonally through the end of that caulk block
jer> ^^ is that what you mean by diagonally?
ydnar> no
ydnar> diagonal in x-y
jer> 8\
ydnar> you had the right idea before
ydnar> btw
jer> oh, darn
ydnar> that caulk brush should be axial
ydnar> not sloped
jer> no slopes?
jer> not knowing axial... just straight up and down, no slopes?

ydnar> jk
ydnar> you have to use q3map_tcGen ivector and not q3map_texturesize for terrain shaders
ydnar> q3map_texturesize will work for normal shaders, however
ydnar> {wf}shadowphong a r_showtris
ydnar> do you know what causes sparklies?
ydnar> t-junctions
ydnar> where there’s an edge on one surface that meets a vert on another
ydnar> and there’s no vert on the first edge
jer> the q3map tcGen ivector
{wf}shadowphong> its a patch
{wf}shadowphong> oh hm
{wf}shadowphong> you mean that brush where the caulk meets.
johnny> which don’t get split for t-junction fixes

jer> ydnar said use non-axial caulk brushes under terrain
ydnar> no
ydnar> axial
jer> err, axial
jer> darn
jer> slow
ydnar> yeah
ydnar> blocks
ydnar> slanted at most on x-y
jer> ok
ydnar> you want the simplest portals possible
jer> http://particle.mindgrid.net/wolfmp/dev/hinting/axial.gif
jer> top down like that
jer> no angles on the z axis
jer> ‘slopes’
jer> brushes with yellow ;p
ydnar> yeah
ydnar> none of that nonsense
jer> heh
jer> slowly learning the ways
jer> nighty night
{wf}shadowphong> thanks so so so much man
ydnar johnny> cy
*** ydnar is now known as ydnar
ydnar> morning
hro> lo ydnar
ydnar> cloudscapes looks lightmapped to me
ydnar> lo hro
ydnar> cloudscapes jacked
ydnar> I’d try a different approach to making canyons than extruded terrain mesh
cloudscapes> ugh wonder how on earth i can make terrain without a heightfield as detailed as this
cloudscapes> cant use 3ds max that’s for sure
cloudscapes> though I’d really like to
cloudscapes> what’s wrong with heightfields?
cloudscapes> besides the lack in overhangs
ydnar> they look like crap when the slope is steeper than 45 degrees
cloudscapes> erg..... was afraid of that
cloudscapes> my backup plan, ditch the lightmap for the terrain, and vertex-paint fake shadows, heh
ydnar> well
ydnar> the trouble is that your terrain is so steep
ydnar> lightmap projection downwards really fails
{wf}shadowspawn> heyya ydnar
{wf}shadowspawn> our mappers are salivating now
{wf}shadowspawn> i wish to thank you again heheh
{wf}shadowspawn> one of our more experienced ones tried out phong and damn him it looks perfect
{wf}shadowspawn> heh but he loves it
ydnar> werd
ydnar> got any shots?
{wf}shadowspawn> got the actual map, i think he does but i don’t know where they are
{wf}shadowspawn> i have a few in lightmap
{wf}shadowspawn> remember that bridge and that hom effect map, was a green tunnel sorta
{wf}shadowspawn> http://www.shadowspawn.net/temp/rshot0030.jpg
{wf}shadowspawn> he moved the light ents since that shot though
{wf}shadowspawn> that’s an old one; he’s using like super 5
ydnar> lol
cloudscapes> can i get the lightmap to be mapped other than downward?
ydnar> tell him -super 5 is a little unnecessary
ydnar> -super 2 -filter (or -extrawide, which is equivalent) is probably the most effective
cloudscapes> i noticed q3map_lightmapaxis z in your sample
ydnar> cloudscapes really, no
cloudscapes> ah..
ydnar> cloudscapes it’d be quite a bit more work on your part
cloudscapes> yeah
ydnar> i.e.
ydnar> you’d have to have layers in your terrain that were mapped on x or y, for instance
cloudscapes> I’m guessing I’d change q3map_lightmapaxis depending on what direction the brush is facing
ydnar> which is entirely possible
ydnar> yeah
cloudscapes> yeah
cloudscapes> well i noticed on your site, your tcGen example, the terrain map x y and z were mapped individually
ydnar> yeah
cloudscapes> but that was one texture
ydnar> that’s pre 2.0.x though
ydnar> you can actually do blends between x-mapped and z-mapped stages
ydnar> have a q3map_tcGen ivector for the first stage
ydnar> and a tcGen vector on the second stage, on a different axis

jerbearw0rk> cloudscapes terrain vis problems?
jerbearw0rk> downloading those screens is taking forever cloudscapes> they’re about 100 kb each
jerbearw0rk> is the webserver 28.8 though cloudscapes> don’t know much about vis, except what it’s supposed to do. don’t know if it’s applicable for an open terrain ma jerbearw0rk> hmm, webserver isn’t responding...
cloudscapes> lol don’t know possible jerbearw0rk> cloudscape is a little bit
{wf}shadowspawn> it did work
jerbearw0rk> cloudscape was dealing with similar problems, but i have a smaller type solution
jerbearw0rk> do you have caulk walls in your ‘hills/mountains’?
jerbearw0rk> (that don’t show through the terrain)
jerbearw0rk> you’ll want as many straight up/down walls inside the terrain as possible, and don’t use angled slope caulk for vis’ing
jerbearw0rk> that’s one thing
cloudscapes> everything but the topsoil is caulked jerbearw0rk> the other is a magic setting, that will make vis data, and compiling time increase by a lot
jerbearw0rk> my vis data alone is like 2mb
cloudscapes> compiling time isn’t a big sacrifice, considering i just need to do it once at the end
cloudscapes> whoa!
jerbearw0rk> but its super optimized
jerbearw0rk> my frames were dropping from a constant 90 to like 30-40
jerbearw0rk> sounds like the same problem you’re having
cloudscapes> jpg links do work, but you need to keep trying, i need a better host, this one’s only temporary
cloudscapes> yeah
jerbearw0rk> cool, its working now
cloudscapes> i really don’t know much about vis
cloudscapes> brb
jerbearw0rk> is this quake3 or Wolfenstein?
jerbearw0rk> i didn’t either, but were probably on similar levels
jerbearw0rk> i can give you an idea
jerbearw0rk> http://particle.mindgrid.net/wolfmp/dev/hinting/terrain_hinting.gif
jerbearw0rk> really bad drawing of caulking ‘inside’ your terrain
jerbearw0rk> http://www2.mindabuse.net/wolfmp/dev/hinting/caulk.jpg outlines of caulk brush in the editor
jerbearw0rk> (but don’t do the sloped caulk like i did at the end of the hill there)
jerbearw0rk> http://www2.mindabuse.net/wolfmp/dev/hinting/axial.gif topdown of caulk, with the yellow line showing you a wall
jerbearw0rk> then what i did is put “blocksize” “256” in the worldspawn
jerbearw0rk> blocksize overrides the default bsp split of 1024x1024 units
cloudscapes> back, let me read jerbearw0rk> k
cloudscapes> quake3
cloudscapes> UT specifically
cloudscapes> ahhh that kind of caulk!
jerbearw0rk> yes
jerbearw0rk> you want to make caulk walls inside the terrain
jerbearw0rk> i know the sides of terrain are already caulked
jerbearw0rk> but the terrain brush as a whole is detail
jerbearw0rk> which means vis goes right through it, the caulk on terrain doesn’t block
cloudscapes> bsp split, will it create a popup effect though?
jerbearw0rk> shouldn’t create a popup effect
jerbearw0rk> not sure what a popup effect is?
jerbearw0rk> heh
cloudscapes> polygons appearing outta nowhere
cloudscapes jerbearw0rk> ah, that shouldn’t happen
jerbearw0rk> that only happens with fogclipping in wolf that I’ve seen
cloudscapes> good writes down the blocksize tip
cloudscapes> thank you !
cloudscapes> I’ll give it a try
jerbearw0rk> http://www.quake3world.com/ubb/forum6/html/019324.html djbob talks about hinting and stuff
jerbearw0rk> yeah
jerbearw0rk> aside from that, there is one more thing
cloudscapes> i realize how crucial it is to optimize a map
jerbearw0rk> http://www2.mindabuse.net/wolfmp/dev/hinting/terrain_hinting.gif
jerbearw0rk> in that image
hro> cloudscape, take a look at my site, halfway down the page is a little prefab of a terrain-map you can see/d-load in the beta section
hro> it pretty much shows how to vis-block in terrain
jerbearw0rk> take a look at the slopes and you’ll see the ‘n’ on the right side is about as high as the player could ever get
hro> http://www.hro.barrysworld.net/
jerbearw0rk> so what you would then do after making your walls is make a giant hint brush that butts up against the sky brush on top and all four sides
jerbearw0rk> and then bring it down as low as possible until the player can’t ever get there
jerbearw0rk> what you’ve done then is created a vis ‘ceiling’
jerbearw0rk> that’s the important key, because without the ceiling
jerbearw0rk> your walls are just walls, which means the vis can see over the wall and potentially draw things behind it
jerbearw0rk> which is what you want to avoid
cloudscapes> jerbearw0 think i understand. I need to create a hint brush that fills the whole skybox (whole world basically) but scale the brush’s height so that it doesn’t go any higher than what the player can potentially get to?
cloudscapes> thanks, I’ll have a look! bookmarked
jerbearw0rk> indeed
cloudscapes> thanks for the golden tip
cloudscapes> i don’t know if there will be problems using that technique though
cloudscapes> since there are multiple height levels of terrain. the player can basically go everywhere on the terrain
cloudscapes> I’ll still give it a try though
cloudscapes> and during lunch break I’ll have a look at hr)’s prefab
cloudscapes> hro i mea cloudscapes> hmmm.. can’t wait to start work on the detail textures
jerbearw0rk> detail textures on terrain are slick, but memory hogs on huge textures
jerbearw0rk> like my 8-layer terrain, if i had a detail texture would be 16 x 512x512 textures
jerbearw0rk> that == holy shit
cloudscapes> yeah
cloudscapes> but i think I’ll use the same tileable 256x256 for all my layers
cloudscapes> maybe two

cloudscapes> wonky skybrush stuff? would changing q3map_lightsubdivide 512 in my skybox shader fix this?
ydnar> no
ydnar> nononoo
ydnar> q3map_lightsubdivide affects light sources

ydnar> cloudscapes seriously
ydnar> use 32 or 64
cloudscapes> hmmmmm...
jerbearw0rk> heheh
ydnar> {wf}shadowspawn what’d be a valid assumption
ydnar> {wf}shadowspawn are you referring to the radiosity code?
cloudscapes> even 16 is too much?
ydnar> yeah
cloudscapes> q3map_bounce 4.0 did wonders to the general lighting of this
{wf}shadowspawn> i think they were just trying to get the base differences down without anything other then fast
cloudscapes> damn
ydnar> the reason you use larger values is because terrains tend to be huge
cloudscapes> yeah
ydnar> and soak up lightmap space + compile time
cloudscapes> but i tried 32 and 16
ydnar> so you use larger values for a coarser lightmap
jerbearw0rk> q3map_bounce 4.0 is just # of bounces for that surface, or added to q3map -bounce # + q3map_bounce #?
cloudscapes> and i don’t mind about compile time
ydnar> if there is no difference between 32 and 16, then what you’re seeing is it hitting the 128x128 lightmap max size per surface
ydnar> jerbearw0o
cloudscapes> no it’s added to the shader to multiply the effect of radiosity
ydnar> that’s emission scaling
ydnar> default is 1.0
cloudscapes> i think
ydnar> q3map_bounce 0.5 means the surface will re-emit half the light it normally would
ydnar> 2.0 means it’d emit twice the light of a normal surface
jerbearw0rk> interesting
cloudscapes> useful
ydnar> a13 had the amped radiosity
jerbearw0rk> i need some type of splash of light from the sun off my terrain
cloudscapes> if you want to create caustics around the edge of the water
cloudscapes> simulated caustics
ydnar> a13 default bounce is effectively 2.5x what previous versions were
jerbearw0rk> gotcha
ydnar> heh, caustics
ydnar> expensive, but fun
ydnar> easier simulated with shader passes
ydnar> you could do it, cloudscapes, with your terrain
ydnar> have a terrain layer that you only use underwater
cloudscapes> yeah, I’m tempted

ydnar> and have a caustics projected shader moving/scaling
ydnar> if you used the blending, it’d fade out nicely
cloudscapes> I’d have to work on the shoreline geometry a bit more though, which I’m doing anyway ydnar> sure
cloudscapes> changes all the q3map_lightmapsamplesize 8 instances in shader to q3map_lightmapsamplesize 16
ydnar> cloudscapes 32
jerbearw0rk> and -filter
ydnar> 16 will probably have zero effect on that map, given how big it is
jerbearw0rk cloudscapes> ok
ydnar> i use 64, personally
ydnar> but either way
cloudscapes
ydnar> ok, going afk for a bit

ydnar> no more tcGen scale on terrain shaders
ydnar> = faster fps all around
ydnar> think of a standard lightmap + texture as your baseline shader
snickelfritz> wow
ydnar> that’s about the fastest (other than rgbGen vertex single stage shaders) through the pipeline
ydnar> think of mapping skills as a cube
ydnar> with 3 axes
ydnar> gameplay, aesthetics, and technical

]s[belac> ydnar i have to anything special with func_groups for terrain now, or is just the same as before?
ydnar> you can have terrain in worldspawn
ydnar> the entity keys have been tweaked
ydnar> “shader” can/should be “_shader”
ydnar> “alphamap” can/should be “_indexmap”
]s[belac> cool, no layers keyword needed?
{wf}shadowspawn> belac didn’t read the logs i sent him
]s[belac> i tried but geez =[
]s[belac> there was a lot
ydnar> oh
ydnar> yeah
ydnar> layers keyword is still needed
ydnar> “_layers”

ydnar alphashadows looks nice
dog-sweetnutz> need twentyseven to fix the snow so i can have falling snow, and then fix up the 3rd tree model
dog-sweetnutz> yea
ydnar> btw
dog-sweetnutz> what’s up
ydnar> if you have any caulk brushes extending up out of the terrain, get rid of them
dog-sweetnutz> alright, don’t think i have any right now
dog-sweetnutz> i think I’m getting some shadows up top because the sky is a little low
ydnar> the terrain in the distance in that shot looks a wee dark
ydnar> ah
ydnar> yeah, the sky/sun code is new in 2.0
dog-sweetnutz> ahhh ok
dog-sweetnutz> I’m going to try raising the sky some
ydnar> what’s your sky shader?
dog-sweetnutz> textures/sweetnutz2/sn_snowterr_sky
dog-sweetnutz> {
dog-sweetnutz> qer_editorimage textures/sweetnutz/sn_snowterr_sky.tga
dog-sweetnutz> surfaceparm noimpact
dog-sweetnutz> surfaceparm nolightmap
dog-sweetnutz> q3map_globaltexture
dog-sweetnutz> q3map_lightsubdivide 1024
dog-sweetnutz> q3map_surfacelight 140
dog-sweetnutz> skyparms env/snowterr/arcn 256 -
dog-sweetnutz> }
ydnar> ok
ydnar> might want to make it a tad brighter
dog-sweetnutz> also i do have some brushes inside the terrain for vis blocking that extend upwards
ydnar> well, 140 should be ok
dog-sweetnutz> yea
dog-sweetnutz> i don’t have any bounce
ydnar> using -light fast?
dog-sweetnutz> i might try that
ydnar> yeah
ydnar> lose any and all caulk brushes that extend up out of the terrain
ydnar> and clip your terrain to the buildings
dog-sweetnutz> clipped to buildings
dog-sweetnutz> the brushes that extend out are textured with sky
ydnar> yeah, not good
dog-sweetnutz> to block visibility
ydnar> better to hint
dog-sweetnutz> well either that or r speeds of 15k
ydnar> and put axial caulk brushes inside the hills
dog-sweetnutz> I’ve got axial caulk inside the hills, so the part that extends upward i can use hint instead eh
dog-sweetnutz> ill try that
ydnar> no, i mean
ydnar> use a horizontal hint
ydnar> and increase blocksize
ydnar> worldspawn key “_blocksize”
ydnar> set it to 2048 or 4096
dog-sweetnutz> alright
dog-sweetnutz> ah wait i did raise blocksize to 2048
dog-sweetnutz> need to learn more about hint brushes, I’ve read a few things on it, but the concept still gets me
ydnar well
ydnar> since terrain is lightmapped
ydnar> having structural brushes extend through the terrain leads to occluded samples
ydnar> + wonky lighting
dog-sweetnutz> yeah i noticed that
dog-sweetnutz> i just thought I’d play with bounce to minimize it since i need to block vis to certain sections of the map
ydnar> bounce won’t fix it
dog-sweetnutz> ah, crappy
ydnar> you can do good vis without putting blocks through terrain
dog-sweetnutz> ah
dog-sweetnutz> going to go read one of those hint brush links again on the forums

jerbear> terrain is expensive for using only one side of each brush jerbear> ydnar with the new terrain system in q3map v2.0.0, would it be possible to use alphamaps on ‘terrain’ that were mapped on the x and y axis?
jerbear> for different terrain entities
rr2do2> jerbear think about that situation
rr2do2> and how you would tile terrain then
jerbear> the same way i do now
jerbear> just rotate the func_group jerbear> it would just project the alphamap on a different axis
jerbear> that’s al jerbear> like a wall of blended textures
jerbear> it might be an engine limitation...
jerbear> thought I’d lay that question out there though jerbear> “terrain” “1”
jerbear> “axis” “y”
rr2do2> you get a seam there likely
jerbear> something like that
rr2do2> seam - seem
rr2do2> htf do you spell it?
jerbear> seam
jerbear> you had it right ;)
jerbear> it obviously wouldn’t blend with the normal terrain projected on the ground
jerbear> i wouldn’t expect it to, its a different axis and a different entity
rr2do2> you could get it working
rr2do2> but not within q3 right now
rr2do2> not unless you create a ton of custom shader
jerbear> no different than normal terrain?
rr2do2> normal terrain is nothing compared to that
jerbear> well, I’m thinking of it in the same way though—it’d be limited to a single axis, or the inverse thereof
jerbear> y, y-, x, x-
jerbear> z-? you could do terrain on the ceiling? heheh
rr2do2> you’d have rotated textures offsets
rr2do2> and texture offsets changing per triangle
rr2do2> and per layer
rr2do2> ;)
jerbear> or inverted, much like scale -0.5
ydnar> well
ydnar> right now the indexmap (alphamap) is hardwired to only work on z axis
jerbear> yeah, that’s what i imagined
ydnar> but you can have terrain layers that blend on a different axis
ydnar> for cliff sides and the like
jerbear> that’s what i was thinking
jerbear> but not limited to blending only on the z axis, if that’s explained correctly
rr2do2> yeah that is what i mean
rr2do2> but if you want a smooth transition you get in a more complicated situation jerbear> obviously
ydnar> lots of layer jerbear> another limitation and hack, much like lightmapped terrain
ydnar> well
rr2do2> hm
jerbear> ydnar being its own func_group, it could just call another metashader
ydnar> you can have 2 different axes in a terrain blend shader
jerbear> or use the same one
rr2do2> I’d create one alphamap for one layer
rr2do2> well
ydnar> one uses q3map_tcGen
rr2do2> it would be a bitmap
rr2do2> as in really bit ;)
ydnar> and the blend stage use tcGen vector
rr2do2> ‘layer there or not;
ydnar> he he
rr2do2> and project it’s usage on the geometry
jerbear> whack rr2do2> then use the engine to build the terrain texturing rr2do2> (or q3map could do it, but with q3 it would be a real mess)
ydnar> he he
ydnar> well
ydnar> if the map file had support for a mesh primitive with explicit vertex alpha
ydnar> and radiant rendered shaders properly
ydnar> then you wouldn’t need to bother with this nonsense
jerbear> god, that would be nice... actual shader rendering in the editor
jerbear> so true * +rr2do2 wonders how to get radiant up to speed enough to allow that
jerbear> true
rr2do2> move away from brushes jerbear> yes
jerbear> that’d be a rewrite of the compiler though, right?
rr2do2> yes
jerbear> i mean, if you went strictly polygon based?
rr2do2> well
rr2do2> not really
rr2do2> only bsp stage
jerbear> yeah
ydnar> well
jerbear> once its bsp’d, you have your polys
ydnar> not really that much of the bsp stage
ydnar> - was doing some hacks in that a little bit ago
rr2do2> mainly the parse jerbear> i mean, it just splits a plane
jerbear> heheh
ydnar> the bsp tree generator takes a single argument list of faces
ydnar> those could come from anywhere.. rr2do2> yup
rr2do2> hmm
rr2do2> if you’d have insides only
rr2do2> you could move to a portal renderer in radiant
ydnar> one could in theory write a maya plug-in
rr2do2> which would make the camera fast while you’re inside the rooms
ydnar> or max plugin that would export a model
rr2do2> (outside just cubic clipping)
rr2do2> aye
ydnar> that q3map could digest
ydnar> would probably take a weekend
ydnar> hm.
ydnar rr2do2> but that doesn’t show shaders in 3d ;)
ydnar> well
ydnar> they have facilities to integrate large programs as plug-ins
ydnar> one could port a shader-parsing/using renderer to a plugin
rr2do2> aye
rr2do2> hopefully performance will be better than with gmax/tempest though
* +rr2do2 shivers
ydnar> and i do believe that maya has a global illumination module
jerbear> ht65.165.2.251/signs/previews/031321312128.jpg
ydnar> so one could in theory put the entire pipeline, soup to nuts, in a maya plugin
rr2do2> lol
ydnar> haha
rr2do2> a18 - with the huggles of jerbear

ydnar> hmm.
ydnar> need maya
ydnar> tired of proprietary editors

jer> hrm
jer> if you were to put q3map_bounce on a terrain shader, would it be common/terrain, or all of your terrain metashaders?
ydnar> metashaders
jer> affirmative, cap’n
jer> there’s 36 metashaders of work to go through jer> bbiab
ydnar> oh btw
ydnar> instead of doing that
jer> hi
jer> heh
ydnar> you should add q3map_lightimage with an image
jer> to get the color
ydnar> so the radiosity has an image determine that
ydnar> yup
jer> ok
jer> so i take it the light will bounce originating from the sun if i do that?
ydnar> it’s using white if no image is found
jer> right
jer> light source is the sun on terrain though, right, so it’d go sun >> terrain (bounce) >> surfaces

jetscreamer> is the q3map_smoothinggroup key implemented yet
]s[belac> hmmm
]s[belac> do i have to put terrain 1 on group?
]s[belac> shouldn’t have to should i?
{wf}shadowspawn> hold on
{wf}shadowspawn> too many things at once I’m doing
{wf}shadowspawn> friggin rcon with quake is such a pos now i need to quit and reconnect every time i change a map
ydnar> ]s[belac keys does your terrain entity have?
ydnar> q3map should be spitting out errors if it can’t do things right
{wf}shadowspawn> ydnar i was looking at some of my notes, you mentioned that radiosity will be calculated off of ents like doors and such now. does that still happen?
{wf}shadowspawn> and what will happen when that door has an areaportal inside it

* +b3dogg kisses ydnar
b3dogg> awesome, my secret door is ready to rock
]s[belac> _shader, _alphamap, and _layers
cloudscapes> ydnar, i have to apologize for being so stubborn
cloudscapes> samplesize 32 seems to be doing the trick nicely
]s[belac> ph should it be _indexmap ?
cloudscapes> 64 is too little detail though, but I’m sure 32 will do fine
*** chanserv sets mol 17
ydnar> yeah
ydnar> saw the recent shots, looking good
ydnar> reminds me of ff movie
ydnar> _indexmap
ydnar> “alpha” is a misnomer
ydnar> so either use old “alphamap” or new “_indexmap”
]s[belac> that didn’t help =[

jer> is it me, or does q3map_novertexshadows no work in q3map2 at all?
jer> i always have terrain shadows.
ydnar> vertex lighting in 2.0.x is much improved
rr2do2> if i use 2.0.x
rr2do2> can i vis with a different executable?
ydnar> yes
rr2do2> kewl
rr2do2> even if i use -meta ?
ydnar> yep
ydnar> vis doesn’t look at dsurfs
ydnar> bspc does, though
ydnar> so in order to make a map with -meta work with bots, you need to use -forcesidesvisible when doing bsp2aas
rr2do2> what do i put in terrain again?
rr2do2> also
rr2do2> what is a good light command line
rr2do2> -light -v fast -shadeangle 90 -super 4 -thresh 0.5
rr2do2> ?
ydnar> common/terrain and common/terrain2 need “q3map_terrain”
ydnar> or alternatively
ydnar> q3map_nonplanar
ydnar> q3map_indexed
ydnar> q3map_shadeangle 179
ydnar> q3map_lightmapaxis z
ydnar> etc
rr2do2> he he
ydnar> q3map_terrain is a proxy for a bunch of that shit
ydnar> dose’s terrain code was a subset of metasurfaces
ydnar> I’d stay away from cmdline shadeangle though
ydnar> -light fast -extrawide
rr2do2> it’s what you suggest in the doc ydnar> is good
djbob> lol
ydnar> yeah, yeah.
rr2do2> now i read the fucking manual
ydnar> it’s really dodgy when used globally
rr2do2> and it isn’t right either ;p
ydnar> haha
ydnar> no official manual for 2.0.x yet
rr2do2> right
rr2do2> so -super -thresh 0.5 fast it is then
ydnar> jetscreamer’s doc is pretty nice though
rr2do2> no -smooth or -extra ?
ydnar> -thresh 0.5 is only useful with phong shading
ydnar> for surface normal recovery
ydnar> -smooth does nothing currently
rr2do2> phong shading is enabled by default right?
ydnar> nope
rr2do2> need to do funky func_group stuff?
ydnar> for what
rr2do2> phong on surfaces
rr2do2> or a shader?
ydnar> no
ydnar> q3map_shadeangle on a shader
rr2do2> bleh
* +rr2do2 cba making shaders for that
ydnar> heh
rr2do2> not right now at least
rr2do2> need to make it in engine
rr2do2> store it in xmlmap
ydnar> phong shading was low on my list of priorities
rr2do2> eh
rr2do2> editor
rr2do2> so.. -super 4 fast then
rr2do2> well
rr2do2> here we go
ydnar> nooo
ydnar> well, ok
ydnar> but -super 4 = 16 samples per luxel
ydnar> = slow
rr2do2> how slow
ydnar> roughly 16x as long as w/o -super
rr2do2> heh
rr2do2> I’ll do it without first then
rr2do2> hm
ydnar> -super 2 -filter is a good compromise
rr2do2> -meta bsp seems to take longer?
rr2do2> what’s -filter
rr2do2> ah
ydnar> 3x3 box filtering
rr2do2> gaussian blur
ydnar> yeah
ydnar> 1 1 1 1 1 1 1 1 1 kernel though
ydnar> could be better