vertexremapshaders...again :)

(RabidCow) #1

Ok, I just can’t seem to get this straight. Lets say I have a simple two texture terrain shader…like this…

textures/tl3/terrain_0
{
q3map_lightmapsamplesize 64
q3map_lightmapaxis z
//q3map_texturesize 512 512
q3map_tcGen ivector ( 512 0 0 ) ( 0 512 0 )
{
map textures/terrain/grassbrown.tga
}
{
map $lightmap
blendFunc GL_DST_COLOR GL_ZERO
tcGen lightmap
}
}

textures/tl3/terrain_1
{
q3map_lightmapsamplesize 64
q3map_lightmapaxis z
//q3map_texturesize 512 512
q3map_tcGen ivector ( 512 0 0 ) ( 0 512 0 )
{
map textures/terrain/grassbrown2.tga
}
{
map $lightmap
blendFunc GL_DST_COLOR GL_ZERO
tcGen lightmap
}
}

textures/tl3/terrain_0to1
{
q3map_lightmapsamplesize 64
q3map_lightmapaxis z
//q3map_texturesize 512 512
q3map_tcGen ivector ( 512 0 0 ) ( 0 512 0 )

{
	map textures/terrain/grassbrown.tga
}
{
	map textures/terrain/grassbrown2.tga
	alphaGen vertex
	blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
}
{
	map $lightmap
	blendFunc GL_DST_COLOR GL_ZERO
	tcGen lightmap
}

}

Of course, I know that these are not optimized but they do work in lightmap. Now, if I add a vertexremap shader like this…

textures/tl3/terrain_vx
{
{
map textures/terrain/grassbrown.tga
rgbGen vertex
}
}

I should be able to point to it from the worldspawn, so that both of the terrain textures are replaced by one, correct? Now this is where I think I may have the wrong idea. I have been searching the threads and have found the “answer” to be removing the worldspawn vertexremapshader key entirely. This does get rid of obvious HOM, but I thought the vertexremapshader was supposed to exchange the texture in it for the multiple textures in your lightmap terrain shader. Anyway, my real question is…how exactly do I write my worldspawn vertexremapshader to point to my texture/tl3/terrain_vx shader for both of the lightmap terrain textures? :slight_smile: I’m sorry if it seems like a dumb question, but the closest I can get is both terrain textures being visible in vertex, just not blended. While I think I can work with that (since I don’t care a great deal about how it looks in vertex light) other mappers are wishing for a single texture to be mapped in place of the two in this example, for instance. Actually, kudos on making both textures appear in vertex :). Thanks in advance for any help you guys can give me :slight_smile:
RC

(ydnar) #2

What’s the exact vertexremapshader key/value pair in the map?

y

(Dragonne) #3

RC and I are both working on the same issue for two different maps, we’ve run into this wall together over the weekend here.

Move over a sec RC… :bump:

I can give you my worldspawn keys, which should match his except for the specific shader name:

“vertexremapshader03” “textures/ut_druglord/dlterrain_0to1;textures/ut_druglord/dlterrain_vx”
“vertexremapshader02” “textures/ut_druglord/dlterrain_1;textures/ut_druglord/dlterrain_vx”
“vertexremapshader01” “textures/ut_druglord/dlterrain_0;textures/ut_druglord/dlterrain_vx”

It’s starting to drive me nutz! :banghead:

(RabidCow) #4

Just found the problem. If the large external lightmap is generated by the q3map_lightmapsize both textures are displayed in vertex mode, just not blended and when I remove that parameter to disable the external lightmap only one texture is displayed, as I originally expected.
RC

(Dragonne) #5

so ummm… what? :???:

(RabidCow) #6

Ok, this is kind of interesting. I wondered if, at some point, ydnar had fixed the need for the vertexremapshader. I totally removed the shader and the worldspawn keys and the map still displayed both terrain textures, just without blending. Even the tcgen ivector settings of the existing terrain shader were used. As anyone that has been making terrain for awhile knows, if you didn’t build the vertex terrain shader, HOM resulted when someone entered the game in vertexlight mode. This actually is a MUCH better alternative, for the default. It would be nice to be able to control this manually, however. One texture is often less objectionable to a gamer than two totally different textures patterned in diamond shapes :), but both can be worked with and there really probably aren’t alot of vertex players anymore…

(Dragonne) #7

Though I would like to see the vertex remap keys work again.

PWEEEEZE! :bash:

:smiley:

(ydnar) #8

Ah shit. Right. :slight_smile:

I’ll reenable the auto-vertexremap code for external lightmap shaders.

BTW, if you’re not using a flat (i.e. snow) colored terrain texture, there’s little reason to use an external lightmap in Q3.

Try removing the q3map_lightmapSize line from the shader(s) and recompiling.

y

(RabidCow) #9

Thanks Ydnar! You’re the best! Haha, I’m addicted to the fine shadows now. With _lightmapscale .1 and q3map_samplesize 2 in the terrain shader, the single 512 lightmap provides beautiful shadows :), even before supersampling for the final compile (actually, I’m kind of torn on that…with a very fine definition lightmap, supersampling just blurs the result too much).
RC

(ydnar) #10

Well, the lowest samplesize is 1 unit. It won’t go any lower, I’m afraid. So q3map_sampleSize 2 and _lightmapscale 0.1 is well, overkill and redundant.

Could you post the terrain shader you refer to?

y

(RabidCow) #11

Well, I look at it this way. A 512 512 single merged lightmap is no problem for the game to render and is easily tweaked once a final compile is done. Since I have lots of computing power and I figure the only downside to a small samplesize and _lightmapscale is compile time, I’m willing to go the whole 9 yards for quality. Tree shadows etc can be much more detailed. I tried all sorts of combinations with internal lightmaps and various samplesizes etc, but none provided the stunning shadows that the large lightmap with extreme detail gave me. Here is the shader for another terrain map I am working on atm…

textures/terr2b/terrain_base
{
q3map_lightmapsamplesize 2
q3map_nonplanar
q3map_lightmapmergable
q3map_shadeangle 120
q3map_lightmapscale .1
q3map_lightmapsize 512 512
q3map_lightmapaxis z
q3map_tcGen ivector ( 1024 0 0 ) ( 0 1024 0 )

}

textures/terr2b/terrain_0
{
q3map_baseshader textures/terr2b/terrain_base
{
map textures/terrain/grassbrowntest.tga
}
{
map $lightmap
blendFunc GL_DST_COLOR GL_ZERO
tcGen lightmap
}
}

textures/terr2b/terrain_1
{
q3map_baseshader textures/terr2b/terrain_base
{
map textures/terrain/grassbrownoriginal.tga
}
{
map $lightmap
blendFunc GL_DST_COLOR GL_ZERO
tcGen lightmap
}
}

textures/terr2b/terrain_0to1
{
q3map_baseshader textures/terr2b/terrain_base

{
	map textures/terrain/grassbrowntest.tga
}
{
	map textures/terrain/grassbrownoriginal.tga
	alphaGen vertex
	blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
}
{
	map $lightmap
	blendFunc GL_DST_COLOR GL_ZERO
	tcGen lightmap
}

}

Here is a screenie showing what should be a smooth curved shadow. No skylight, ambient light etc so the shadow is too dark atm.

It is nearly smooth now with no supersampling etc. I’m sorry the screenie doesn’t do justice to the technology, but if the map had trees, for instance, the individual leaves are visible in the shadows :)…overkill? maybe, but since I don’t have a problem with the external lightmap and it is held to being only one for all the terrain, I figure “go for the gusto” :slight_smile:

(RabidCow) #12

Actually, Ydnar, you mentioned “redundant” in your comments on my settings. Would that be the q3map_lightmapscale? Is it not doing anything because I have set the lightmapsize? I was using it in my worldspawn and then decided to limit it to my terrain, but didn’t really think it though…Thanks for all the help, btw. I can’t believe that the shadows we now control on terrain are the “hack” (your words) that you started a while back :). I once tried changing a terrain map into a phong shaded func_group that was not terrain, so I could see player shadows. This allowed shadows to work as they were designed to, but, surprisingly, optimized lightmapped terrain looked just as good or better in the shadows while having the additional smoothing etc of the terrain entity. Fab job!
RC