Terrain blending tutorial for noobs by Seven_dc

[MadJack]

Alright.

Did some tests with no alphamaps and there are no noticeable changes so I’ll stick with no alphamaps as suggested by seven_dc unless something else pops up on that subject. In fact I used the textures as they’re distributed in ET from my shader.

Also, I noticed that dime use q3map_tcGen ivector ( 512 0 0 ) ( 0 512 0 ) in his shader and from my compiles tests, it didn’t change anything. In fact, the surrounding terrain (easygen) is at 512 too and there is a definite difference in texture scale between the alphamap and alphamod with or without ivector. That difference is the exact same. I wonder if ivector should scale the textures. (You can see a glimpse of the texture scaling in the picture above).

I’m a bit surprised to find that the blending fade linearly. There are places where my brushes are wider but the blend seems to be the same no matter what the width of the brush. What I wouldn’ve like to see is a blend happens within X pixels/units. If there’s more place, use the unblended texture (since it’s all blended now). I guess I was expecting something similar to dot2. I’ll think about using ratty’s way of doing things.

[dime1622]

yes, i still have a problem with my shader. the grass texture’s pixels are much smaller in the blend than outside the blend, but im too dumb to know how to fix it.

[ratty_redemption]

guys, the q3map_tcgen ivector values of ( 512 0 0 ) ( 0 512 0 ) should only be noticeable if were scaling images that arent saved at 512x512 pixels, ie if they are originally larger or smaller dimensions…although I`m not aware of any problems with leaving q3map_tcgen ivector in, if it is the same size as the image.

if you have a image that is scaling in game too much then try different values for the q3map_tcgen ivector, eg ( 256 0 0 ) ( 0 256 0 ) or ( 1024 0 0) (0 1024 0 )

the problem is with multistage shaders using different sized images to start with, as q3map_tcgen ivector will scale all images in that shader, unless we use tcgen vector (not q3map_tcgen ivector) on the 2nd stage or 3rd stages etc to overide it, but the q3map one is quicker as it`s scaled at compile time and not in game, so only use other one if you really need to as it will affect fps.

ideally wed rescale any additional images past the first shader stage in a paint program, but that would make our pk3s bigger, so I tend to scale them at compile or run time, unless I`m using custom tex not included in the original game.

eg of one of my dotproduct shaders showing the two different scaling parms.

textures/_ratty_terrain/dirt_rock_blend  // rock wall, dirt transition
{
 qer_editorimage textures/_ratty_terrain/grey_terrain.tga
 q3map_lightmapsampleoffset 16
 q3map_lightmapmergable
 q3map_shadeangle 178
 q3map_tcmod rotate 33
 q3map_nonplanar
 q3map_forcemeta
 q3map_alphamod dotproduct2 ( 0 0 0.84 )
 q3map_tcgen ivector ( 512 0 0 ) ( 0 512 0 )
 surfaceparm grasssteps
 {
  map textures/_ratty_terrain/ratty_dirt_m03.tga  // dirt transition
  tcgen vector ( 0.00390625 0 0 ) ( 0 0.00390625 0 )  // 256x256 size
  //rgbgen const ( 0.6 0 0 )  // uncomment to debug
 }
 {
  map textures/_ratty_terrain/ratty_cliff_m05dcon.tga  // rock wall
  alphagen oneminusvertex
  alphafunc ge128
 }
 {
  map $lightmap
  tcgen lightmap
  blendfunc filter
 }
}

the rock tex is 512x512 but the dirt tex is only 256x256, the hard part is working out the values for tcgen vector, which I use windows calculator for, the equation being 1/n where n is the image size we want, eg 1/256 = 0.00390625.

also if your getting misalignments between blend shaders and normal ones, then check the q3map_tcmod rotate values are the same, if your using those, otherwise some shaders with be rotated differently to others, which we may not want.

[MadJack]

@ ratty, my easygen textures are with ivector 512 and I want my volume textures to be the same size. ivector didn’t change a thing. The scaling is the same with either 512 or 1024. From the tests I did, there were no changes. It’s as if the scaling didn’t occur. It might be me but I really don’t think so. I checked the image and it’s 512x512 but it’s far from being the same size on the alphamod and the terrain.

I’ll try using vector in the texture stage instead and see what it does.

[ratty_redemption]

@MadJack, you should be seeing some effect of the ivector if you change its values, post your shader and well try to debug it if we can.

also what happens if you comment out the ivector in your easygen shader? I`m guessing it would be scaled the same as the volume shader is scaling?

by default, q3map_terrain used to set up q3map_tcGen ivector ( 32 0 0 ) ( 0 32 0 ) which is very small, but ydnar may of altered that for et?

[MadJack]

@ ratty, as I said, there was no changes with either 512 or 1024 or no ivector. You guessed wrong for the easygen terrain with no ivector The textures are tiny. Much smaller than the alphamod ones (as seen in the pic below) which don’t have ivector either.

Here’s the alphamod shader:

textures/ebe/road_alpha
{
	qer_editorimage textures/temperate_sd/dirt_m03icmp_brown
	q3map_forceMeta
	q3map_nonplanar
	q3map_shadeAngle 179
	surfaceparm landmine
	surfaceparm gravelsteps
	{
		map textures/temperate_sd/dirt_m03icmp_brown.tga
		rgbGen identity
	}
	{
		map textures/temperate_sd/master_grass_dirt3.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
		alphaGen vertex
	}
	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
	}
}

As a reference here’s the terrain_base shader of my terrain:

textures/Ebe/terrain_base
{
	nopicmip
	q3map_lightmapaxis z
	q3map_lightmapmergable
	q3map_lightmapsamplesize 32
	//q3map_tcGen ivector ( 512 0 0 ) ( 0 512 0 )
}

So if the default q3map_terrain ivector is 32, that’s why the terrain textures below are so tiny and not the same size as the alphamod’s.

[ratty_redemption]

@MadJack, this is odd, as I don`t see anything in your road_alpha shader that would be affecting the scaling, certainly not overriding the effect of ivector, and I assume you had it with the other q3map keywords in the top stage?

I don`t understand how the ivector is working in your terrain shader but not the volume one?

if you change anything in your volume shader do the results change in game?

I don`t think the vertex alpha data, contained in the bsp after compiling with alphamod shaders, then has any effect on the tex other then transparency (alpha)

Im pretty sure Ive changed tex or rewritten shaders and the vertex alpha have still worked without me needing to recompile the map, so I don`t think they are the problem, but I know the q3map_tcgen ivector needs recompiling if we alter the scales, unlike the per stage tcgen vector which we can alter as it only used at run time.

perhaps ydnar can throw some light on this bug?

[MadJack]

Alphamod texture scale is definitively 128. I tested the ivector in the easygen terrain and it scales pretty close. As for tcmod… I prefer not to think about that yet. Seems like a lot of tweaking and testing to get that right.

[MadJack]

@ ratty: if you’re wondering about ivector changes, no. No changes in the alphamod volume, adding, changing values will affect it. It’s like the ivector is completely ignored. Though if you’re wondering if any other changes makes any difference then the answer is yes. But again, it depends on what is changed. Changing shadeAngle to 175 won’t change much.

I’m aware of compiling issues with ivector. That’s why I use regioning, much faster than doing the whole terrain. That’s why texturing looks so ugly in the terrain pic I previously posted too.

I’ll try checking if I can find anything useful in q3map2’s source. Not that I’m a code guru or anything but maybe something will jump at me. It’s worth a try…

[MadJack]

Jahaa!

Found out how to fix the scaling. Though I would have prefered if it was done at compile time, I guess we should be happy since we, at least can scale it

Simply add a tcGen vector to the stage that has the texture you want to scale.

Here’s my shader with the fixed scaling + comments

textures/ebe/road_alpha
{
	qer_editorimage textures/temperate_sd/dirt_m03icmp_brown
	q3map_forceMeta
	q3map_nonplanar
	q3map_shadeAngle 179
	surfaceparm landmine
	surfaceparm gravelsteps
	{
		map textures/temperate_sd/dirt_m03icmp_brown.tga
		rgbGen identity
	}
	{
		map textures/temperate_sd/master_grass_dirt3.tga
//  Since this stage deals with the texture I want to scale I just add the following line to scale it every 512 units:
		tcGen vector ( 0.001953125 0 0 ) ( 0 0.001953125 0 )
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
		alphaGen vertex
	}
	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
	}
}

I tried using q3map_tcGen ivector instead of tcGen but from what I could see q3map2 doesn’t iterate the stage so the engine choked on the line telling me it wasn’t recognizing the “(” Changing the q3map2_tcGen ivector ( 512 0 0 ) ( 0 512 0 ) to tcGen fixed that.

@ ydnar, how about making q3map2 scale the textures with q3map2_tcGen in alphamod in the next release? Doable? Useless? MMOB?

[ydnar]

If you want to match up terrain texturing, make sure the shaders all use identical ivector values.

y

[MadJack]

@ ydnar: I tried using ivector 512 for both easygen terrain and alphamod shader but the latter kept the texture scaling at 128. Changing it to 1024 didn’t change anything either. The texture is 512x512 but is getting scaled down with alphamod?

With the above method, I got it to blend perfectly. Didn’t even have to tcMod it. It seems it applied itself very nicely everywhere. I know it’s my eyes but it even seems to blend itself with an already blended easygen terrain.

Anyway, here’s what it looks like:

Here’s the illusion of blending with easygen terrain:

[ratty_redemption]

@MadJack, when you tried the q3map_tcgen ivector instead of tcgen, was that on the same line or moving it to the top stage of the shader with the other q3map lines?

Alphamod texture scale is definitively 128. I tested the ivector in the easygen terrain and it scales pretty close

so does this mean your 1st stage of your shader is being scaled at 128?

Im not doubting the results your getting, but Im personally not having any scale problems with using any alphamod shaders, whether they be dotproduct or volume.

I wonder if anyone else here is getting weird results like you are?

what version of q3map2 are you using? I`m using 2.5.15

edit: nice pics and another good example of what we can do with the new blending

we just have to figure out why your scaling problem was happening, or we could run into that again.

[MadJack]

@ ratty, I tried it at both places (not at the same time of course). Maybe the placement of the q3map2_tcGen ivector is important? I can’t remember where it was placed when on top so maybe that’d be it? Maybe placing it first or last would make a difference. I’ll try to check if there’s a backup of that somewhere…

I think it means the alphamod scaling defaults to 128. Now I have doubts because if the placement of ivector is important the scaling would be some kind of side-effect, not real scaling but rather a by-product of whatever is beind done to the texture before/after the ivector. Does that make sense?

I think I need to rewrite the way I get the 128. Since I tried scaling the alphamod texture and didn’t succeed, I changed the easygen ivector until I got the same scaling as the texture in the alphamod. 128 was the result. I’m not saying I “made it scale” to 128. It seems, from my tests, that’s the default scaling.

I run 2.5.15 and even tried 2.5.14 yesterday with same results.

[ratty_redemption]

I understand all you said there, and Im not doubting you at all, but Im still puzzled as to why there is an apparent default scaling since I haven`t seen this myself.

all my tests have used the original scaling of the tex, or the ivector, vector values I`ve overridden them with.

there is the older tcmod scale you could try on the image stages, eg tcmod scale 0.5 0.5 which would be half the original tex scaled to fit the same surface, ie those values would scale up the tex.

but I think that is slower to draw then vector in game, although q3map_tcgen ivector, is the fastest as its calculated at compile time, if I havent mentioned that already.

for reference, all q3map_ keywords need to be in the top stage, as the game engines won`t recognize them at run time.

[MadJack]

Yeah, I understand why you ask the questions. It’s beyond me why it doesn’t work.

I know that in some instances the order of which q3map2_* are given are important, that’s what I’m wondering about. Maybe that’s what is causing the texture not to scale. Can you post your q3map2_* part of the shader?

I’ll try some stuff and check back in a couple of hours or so. I hate RL stuff competing with mapping stuff

Edit: Spchelling :eek:

[ratty_redemption]

Ill be soon posting my updated shaders in the other terrain tutorial as Im converting them to use q3map_baseshaders and finishing off my 2nd chapter of that tutorial, Ill also do some tests with the various scaling on my volume shaders and report back in this topic, if I find any difference the ordering of the first stage keywords makes, I know they do with other things like light images so it is possible.

[ratty_redemption]

not sure if this will help anyone, but I just noticed this warning in the q3map2 shader manual, linked to in my sig

the base shader must be specified before any shaders that subclass it. Some EasyGen terrain templates incorrectly specified the base shader after the terrain shaders that depended on it, resulting in some interesting errors.

here`s the page it was on.

[MadJack]

That issue is the old “My textures look dumb and tiny in terrain! Why?” question we have about every week in the level design forum.

I wish it was that easy

Anyway, I’m back home now and I’ll make some tests. I’ll post later.

[ratty_redemption]

understood, and Im stopping for today, although I didnt get round to testing the volume tex scaling, which I`ll try to do tomorrow.

but I`m waiting for a reply to my q3map_baseshader question, hopefully from ydnar, before I finish tweaking all my terrain and water shaders.

I hope they all work after and I haven`t made any silly typos or cut n paste errors, which I occasionally do.