3 questions...

[obsidian]

Just a few shader related questions:

1. How do I hide Q3Map only shaders from the editor? For example, how do I stop base shaders from appearing in Radiant’s texture window?

2. If referencing a baseShader with a :q3map suffex, do I write:
   q3map_baseShader textures/blah/blahbase:q3map
   or just
   q3map_baseShader textures/blah/blahbase

3. I have a shader text file named “obsidian_terrain” that was getting too large and difficult to manage, so I want to split it up into 2 shader text files - “obsidian_terrain.shader” and “obsidian_terrain2.shader”. The contents of both shader text files contain shaders with names like “textures/obsidian_terrain/ground”. There is no “textures/obsidian_terrain2/ground”. Do I actually have to list “obsidian_terrain2” in the shaderlist.txt? I want to remove it from the shaderlist since it creates an empty texture group in Radiant, but I’m unsure if there is any adverse effects with Q3Map2 not finding the correct files.

[obsidian]

Actually, make that 4 questions:

I have a terrain blending texture that I want to add a detail shader to. Problem is this, for a 2 texture blend shader the lightmap should be the last stage, right? For a shader with a detail stage, the lightmap should be first, with the detail stage last. So if I want to make a shader with 2 texture stages, a lightmap and a detail stage, where am I supposed to put the lightmap and where do I put the detail stage? Is there any workaround?

[ydnar]

1. You can’t, sorry.

2. A base shader should be abstract and never actually used in-game or applied to any brushes or models. The :q3map suffix is ignored by Q3Map2 and the shader should be referenced without it. The game will ignore the shader.

3. shaderlist.txt should list the filenames of the shader scripts (minus the .shader suffix, of course). Having the name of the shader script match the shaders inside of it is convention and not required. It’s just cleaner and a little easier to find stuff.

4. The detail stage should be last despite what the shader manual says, with blendFunc GL_DST_COLOR GL_SRC_COLOR. The total order is lightmap, texture, detail texture.

y

[WolfWings]

1. You can’t, sorry.

2. The detail stage should be last despite what the shader manual says, with blendFunc GL_DST_COLOR GL_SRC_COLOR. The total order is lightmap, texture, detail texture.

Re: 1) You’d have to get the GtkRadiant folks, or your editor of choice to support such filtering. They simply don’t right now. Possibly setting up a Radiant-only ‘shaderlist.txt’ with some funky double-configuration and double-installs might work.

Re: 4) What about if you’re doing funky things like alpha-tested textures? Would it be okay to, for instance:
{
alphaTest GE128
map BaseTexture
}
{
blendFunc Blend
depthFunc equal
map BlendTexture
}
{
blendFunc filter
depthFunc equal
map $lightmap
}
{
blendFunc detail
depthFunc equal
map DetailTexture
}

Obviously, I left out things like marking the detail stages as detail so they can be disabled by the client, but would the above ‘order’ be a valid one?

[obsidian]

Right, well lets say I did this:

lightmap, texture (filter), texture (blend),detail (filter) - the blend texture will obscure the lightmap… but detail stage would work correctly.

If I did this:

texture, texture (blend), lightmap (filter), detail (filter) - the detail stage probably won’t work correctly since lightmap should be the first stage… but it would look right.

Do detail textures not work with multi-staged shaders?

[ratty_redemption]

I dont use detail myself but Ive seen it a lot in ja and et tex, this is from the et mp_siwa.shader

textures/mp_siwa/lmterrain_0to1
{
	q3map_baseshader textures/mp_siwa/lmterrain_base
	surfaceparm landmine
	surfaceparm gravelsteps	
	{
		map textures/desert_sd/sand_wave_desert.tga
		rgbgen identity
	}
	{
		map textures/desert_sd/grass_sand_flat.tga
		rgbgen identity
		alphagen vertex
		blendfunc gl_src_alpha gl_one_minus_src_alpha
	}
	{
		map $lightmap
		blendfunc gl_dst_color gl_zero
		 
	}
	{
		map textures/detail_sd/sanddetail.tga
		blendfunc gl_dst_color gl_src_color
		detail
		tcmod scale 6 6
	}
}

hth

[ratty_redemption]

@WolfWings, I`ve never heard of blendfunc detail or alphatest ge128, are they valid keywords?

I guessing the latter should be alphafunc ge128?

[obsidian]

ydnar: Thanks for the reply. Too bad about hiding base shaders. Would it be possible to have a directive or shader name suffix that hides the shader from Radiant? Or would that have to be coded into Radiant?

Thanks Ratty, that shader looks like it should do exactly what I have in mind. I was looking at some of the shaders used in Alice, pretty much all textures used in that game had a detail stage attached to it - except for those with multiple blended stages.

[WolfWings]

First, as for placing the lightmap at the beginning or end… the only reason NOT to do so is to use alpha-masked textures light grates and similair.

Though if you want to do lightstyles, IIRC, having the lightmap stages first can improve the quality in some cases for near-black areas. A compromise that eats up some fillrate is to render the ‘masking’ texture similair to this:

{ // Render the 'masking' element of the grate texture
  alphaFunc GE128
  blendFunc GL_ZERO GL_ONE
  depthWrite
  map grates/masked.tga
}
{ // Render the 'lightmap' pass in the masked areas
  depthFunc equal
  blendfunc normal
  map $lightmap
}
{ // Render the actual grate texture
  alphaFunc GE128
  blendFunc filter
  depthWrite
  map grates/masked.tga
}

Though I still think GT0 looks better than GT128 in some cases, notably things like chain-link that are more than 50% ‘transparent’ so they end up vanishing at longer distances with GT128.

@WolfWings, I`ve never heard of blendfunc detail or alphatest ge128, are they valid keywords?

I guessing the latter should be alphafunc ge128?

Yeah, it should be alphafunc, was typing from memory and I always mix up alphafunc as alphatest for some reason.

And at least on Q3A, ‘blendfunc detail’ worked. I don’t know if it’s an ‘official’ blendfunc, or just a happy coincidence that it worked, or what, but it did as intended with setting the ‘detail’ blending mode.

As a quick note… the ‘official’ Q3Map ‘shader_manual’ docs are wrong. “blendFunc filter” is NOT “GL_DST_COLOR GL_SRC_COLOR” like the manual (http://www.shaderlab.com/q3map2/shader_manual/ch6.html#detail) says it is.

[ratty_redemption]

@obsidian, cool

@WolfWings, understood and thats an interesting shader you posted, Ill try masking tex like that next time I use them, normally I just vertex light alphafunc ge128, but it would be cool to have good lightmaps working with them.

and I thought blendfunc filter was blendfunc gl_dst_color gl_zero, ie the default blending on any lightmap tex that doesn`t use a custom shader.

which I agree is different from blendfunc gl_dst_color gl_src_color, which produces more color saturated results iirc …although I`m sure ydnar or someone else can explain technically what the difference is.

[obsidian]

As a quick note… the ‘official’ Q3Map ‘shader_manual’ docs are wrong. “blendFunc filter” is NOT “GL_DST_COLOR GL_SRC_COLOR” like the manual says it is.

Yeah, I noticed that last week… It’s already been changed for the next release.

[ratty_redemption]

cool

[WolfWings]

“blendfunc detail” is different in one very subtle but very, VERY important way from “blendfunc filter” actually, but it’s also incredibly simple.

Detail-mode can multiply the colour value of a pixel from 0.0-2.0, filter-mode can only multiply it from 0.0-1.0

Also, detail-mode doesn’t work except in 32bpp buffers, or at all on ATI Rage 128 cards. Filter mode works always, on all cards, all the time, because it doesn’t rely on the precision of the video-card buffer to function.

So, if you’re using ‘detail’ lightmaps, all you’re doing is doubling the effective value of said lightmap, and at the same time ‘shoving’ r_mapoverbrightbits higher by 1, more or less. It’s not QUITE that simple, but it’s a good approximation for understanding. I think you can set up the options for Q3map2 to actually take advantage of the added dynamic range ‘detail’ lighting would give you, if you don’t mind drop-kicking everyone using 16bpp buffers pretty much out of playing your map.

[WolfWings]

Oh, and I made a typo before. My ‘$lightmap’ stage in the second shader should have no blendfunc at all, so the lightmap is directly rendered in the ‘masked off’ area. I corrected the post itself.

[ratty_redemption]

@WolfWings, interesting posts