Some Qs.

[Hipshot]

Is there any way to remove the subtle 'bobbing' of a camera? And, is there a way of increasing the visible range of it? I think I've looked into these things before, but I don't remember the answer. A normal mirror seems to work at any distance.

What is the best compile/map/shader settings for the most accurate and sharp lightmap. Getting a bit spoiled with Source and its extremly good lightmap, and I get a bitt annoyed in Q3 when trying to make bumpmaps and the lightmap isn't near anything called sharp.

[dzjepp]

You mean cg_bobpitch 0, cg_bobroll 0, cg_bobup 0, cg_runroll 0, cg_runpitch 0? And cg_fov?

[Hipshot]

Uhm.... no...
Maybe you should go back to general discussion j/k

[Kat]

Those settings dzjepp mentioned are what you'd use if you're talking about altering the players point of view; by 'camera' it's assumed you're talking about that camera?

I don't think you can increase the distance, not as we understand that to mean, the only thing you can do iirc is change the FOV which gives the impression of making things close/far (the 'zoom' key decreases the FOV iirc) but it also changes perspective.

[$NulL]

Add spawnflags 4 to the misc_portal_camera to stop it wobbling.

A portal's maximum visible distance is determined by alphagen portal X in one of the shader stages. Where X is the maximum visible distance in game units. If you remove that line/stage it should work at any distance. (Not checked yet)

[Lukin]

What is the best compile/map/shader settings for the most accurate and sharp lightmap. Getting a bit spoiled with Source and its extremly good lightmap, and I get a bitt annoyed in Q3 when trying to make bumpmaps and the lightmap isn't near anything called sharp.

Put bump-mapped brushes into func_group and then add key "_lightmapscale" with value ~0.01 to it.

[obsidian]

You will need to flag the surface as a portal with the "portal" general shader directive as well as add "alphaGen portal N" to the last texture stage, where N is the distance in game units at which the portal view fades completely to opaque.

As an (untested and possibly not entirely functional) example:

Code: Select all

// Simplified shader example
textures/obsidian/portalgate
{
	portal	//flags surface to behave as a portal
	qer_editorImage textures/obsidian/portaleditor.tga
	{
		map textures/obsidian/portalsfx.tga
		rgbGen identity
	}
	{
		map textures/obsidian/portalfade.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		alphaGen portal 512	//fades to opaque after a
					//distance of 512 game units
	}
}

And also an example of a portal shader used in Q3:

Code: Select all

// Vanilla Q3 portal shader
textures/sfx/portal_sfx
{
	portal
	surfaceparm nolightmap
	deformVertexes wave 100 sin 0 2 0 .5
	{
		map textures/sfx/portal_sfx3.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		depthWrite
	}
	{
		map textures/sfx/portal_sfx1.tga
		blendfunc gl_dst_color gl_zero
		tcMod rotate 360
	}
	{
		map textures/sfx/portal_sfx.tga
		blendfunc gl_one gl_one
		rgbgen wave inversesawtooth 0 .5 .2 .5
	}
	{
		map textures/sfx/portalfog.tga
		blendfunc gl_src_alpha gl_one_minus_src_alpha
		alphagen portal 256
		rgbGen identityLighting	
		tcmod rotate .1 //.1
		tcmod scroll .01 .03
	}
}

[Hipshot]

Sorry, I should have replied to this long time ago, I found out how to make the distance long time ago, figured the 256 value was a distance, I decided not to use portals for my teleports anyway so...
The biggest problem is the lightmap, even if, can you maybe tell me the most advanced lightsettings possible to use when compile... skip bounce.

[obsidian]

On the subject of normalmaps, Q3 - unlike HL2 or Doom3 - does not support any kind of dynamic or per-pixel lighting, so normalmaps are really just a really clever lightmap hack. Lightmap luxels are much larger than your typical texel, so the only way you can make Q3Map2 normalmaps look good is to scale the lightmap resolution to some very high value, either using _lightmapscale in the func_group entity value/key pairs or in the shader using q3map_lightmapSampleSize. Lightmaps done this way take up more texture memory, so be prepared for a possible performance hit.

[Hipshot]

Hmm ok, thanks, might be the reason why it looks so crappy then...

Another thing, in a detail texture, you use 'detail' as a parameter, and that makes, so that you can turn off details with the command r_detailtextures 0, if I put this parm on a non detail texture, can I remove other stages then? Like, if have a glass texture that looks really good, but takes lots of performace, then people can just run the map with detailtextures 0 and get a clean glass texture... I can of course try this, but its faster asking, if you don't know I'll just try...

[obsidian]

Detail textures are just a normal texture overlayed on top of the other stages, repeating at a relatively high frequency to make the texture look like a higher resolution image. So yeah, you can use detail on pretty much any texture so long as it follows the very specific rules required by the detail directive (see Q3Map2 Shader Manual for details).

Though the performance advantage/disadvantage on as single shader on your map will be relatively small. It is much more useful when used as they did with games like American McGee's Alice, where pretty much every single texture used in the game used a detail shader. For Alice, it meant 1 less rendering pass on every single surface.

But I suppose if you have some crazy glass shader with 3+ rendering passes, then disabling 1 rendering pass will at least contribute to some performance benefit.

[Hipshot]

I have no glass, this was just an example Obsi... speakng of almost every surface using detail textures, that I have. :icon29:

[o'dium]

The short answer is; Yes.

A detail texture and a detail texture in Quake 3 are two different things who wanted the same goal.

An average detail texture is that which can be seen in the Unreal series. It has a low filtering rate which samples it out quicker than other textures, which means if you stand 10 feet away from the wall, you wont see it. However, the blend function of the texture draws it finely over the top of the original surface, making it appear at close range to having a finer detail.

In Quake 3, this is not the case. Detail textures are there ONLY for the very fact you hinted on, stages that can be disabled by the maker which are deemed expensive. If you was to make a detail texture in the classic sense inside doom 3, it would look the same as Unreal, but without the high sample rate, which would mean you could still see it half way over the map. This looks ugly as sin and should never be used.

Detail, in Quake 3, is a shader flag given to texture artists to place on a stage that they would like to disable if possible. For example, a stage that may be fillrate heavy or "advanced" (Hardly the case in Quake 3, but you know, back then.)

In Quake 2 Evolved we went one step fuurther. Well, about 20 steps. We have given the texture artist the choice of any Cvar, and the ability to make SEPERATE shaders depending on whether or not a cvar is flagged at 1/0 or whatever.

Why?

Well, what about fancy water that used fragment programs, but the player doesn't have a fragment campatible card? Cube maps look good but old old cards dont support them, so the texture would come up as "missing", so we give them a fallback path/shader that doesn't look as good, but means it will work. Shit like that.

[Black_Dog]

Detail textures almost certainly use exactly the same blend in Q3 and Unreal, and Doom if you care to add them. Unreal culls detail textures once they are far away enough to be mip-mapped to invisibility, that's all. Also, the "high sample rate" (?) isn't any different per engine for the simple reason that it's specified as a texture coordinate scale in the shader definition. So I don't know what the hell you are on about.

Regardless of any of that, "detail" will function just fine as a stage culling device. You could do things like put it on half the shaders in a dense particle effect or on a few of the branches of a tree a la CoD. Or hey, even detail stages. Most people will have never set r_detailtextures to anything but 0 though, so I dunno how effective that'd be as a performance control.

[o'dium]

black dog, dont be so quick to jump on the defensive. You now mention "it uses the same blend mode as X so it must be the same" yet leave out its up to the shader writer WHAT blend mode he/she uses.

[Black_Dog]

I don't want to get pissy. The thing is, it's not up to the level designer which blend mode to use. Detail textures pretty much have to use something equivalent to gl_dst_color gl_src_color. This multiplies the detail texture by the framebuffer value and then adds that value to the result again, which will draw the details in the texture but not change apparent brightness (given a proper detail texture of average rgb 0.5).

Blend modes like gl_one gl_one or gl_dst_color gl_zero can't do that, because they only brighten or darken the framebuffer. That means they can't be used for detail textures.

[Lenard]

What the fuck are you talking about.

[Kat]

That was almost in ydnar speak..!

[obsidian]

What the fuck are you talking about.

Are you deliberately trying to throw more fuel in the fire or did you feel that by saying that you had somehow contributed something important to this conversation?


Kaziganthe's quoting the Shader Manual, here:
http://shaderlab.com/q3map2/shader_manu ... tml#detail

Problem with this conversation is that everyone is right to a certain extent... so some clarification:

blendFunc GL_DST_COLOR GL_SRC_COLOR has to be used with detail textures if you want to maintain approximately the same colour/brightness of the original texture stage (assuming the detail texture's average intensity is roughly a middle grey). Any other blendFunc will either significantly brighten or darken the resulting value.

Any detail texture is just a normal texture scaled down relative to the normal texture stage so that it has a greater number of texels per unit squared than normal. Problem with scaling any texture down to these extents is that you get the eventual tiling effect, which looks ugly.

Quake 3 will mipmap detail texels with distance as normal, but it will not cull them from being drawn (though you can do this pretty easily with some clever haxoring - hrmmm, something for me to toy with). You may get a noticable tiling effect with distance, but this can be minimized by tweaking the detail texture to ensure that it tiles properly.

I don't think Unreal culls detail texels completely either but hides them from view by fading alpha values out until they are no longer visible. Advantage is that you won't get any more of a noticeable tiling effect than the base texture since the detail stage fades out with distance. Fill-rate wise, I think is the same, since the texels are not culled, just invisible.

[Lukin]

Kaz, couldn't you just give us a sample shader?

[obsidian]

Kaz, couldn't you just give us a sample shader?

See shader manual... direct link above in my previous post.

If you want to see Q3 detail shaders in action, go buy American McGee's Alice... detail shaders on almost every surface. It should be super cheap now since it's an older game. I would recommend playing it anyway since it's truly an amazing game that's worth the time and money even if you paid full price.

[Lukin]

I just thought it would be cleaner if Kaziganthe just show us the shader instead of describing it.
I played "Alice". Indeed it's an amazing game. And I actually know what detail texture is. Other game that utilizies this "technology" is "Painkiller". Though it is not based on "Q3" engine it's a good example to show what detail textures are. In "PK" all surfaces have detail stage on them - you can turn it off in menu and observe the difference.

[Hipshot]

Here's a sample for you...

Code: Select all

textures/hipshot_is/tile_03
{
	q3map_globalTexture
	{
		map $lightmap
		rgbGen identity
	}
	{
		map textures/hipshot_is/tile_03.jpg
		blendFunc filter
	}
	{
		map textures/hipshot_is/detail.tga
		blendFunc GL_DST_COLOR GL_SRC_COLOR
		detail
		tcMod scale 7 7
	}
}