sky hiccough

[RojaN Returned]

This is an odd thing. When I look at this sky in q3ase, the animation loops smoothly, but in-game there is a visible jump when it loops. Here's the shader:

Code: Select all

textures/outrage/outskybox
{
	qer_editorimage textures/outrage/outsky.tga
	surfaceparm noimpact
	surfaceparm nolightmap
	surfaceparm sky
	q3map skylight 120 6
	q3map_globaltexture
	q3map_sunExt 1 1 0.85098 170 167 83 3 32
	skyParms env/ofar 512 -
	{
		map textures/outrage/outsky.tga
		blendfunc blend
		tcMod scroll -0.1 0.1
		tcMod scale 0.8 0.5
		depthWrite
	}
	{
		map textures/outrage/outsky.tga
		blendfunc blend
		tcMod scroll -0.2 0.3
		tcMod scale 0.8 1
		depthWrite
	}
}

Anything obviously wrong here? The shader works, absent this glitch. Do the scale and scroll of the cloud layers need to be mathematically related?

[sst13]

Try it this way:

Code: Select all

textures/outrage/outskybox
{
	qer_editorimage textures/outrage/outsky.tga
	surfaceparm noimpact
	surfaceparm nolightmap
	surfaceparm sky
	q3map skylight 120 6
	q3map_globaltexture
	q3map_sunExt 1 1 0.85098 170 167 83 3 32
	skyParms env/ofar 512 -
	{
		map textures/outrage/outsky.tga
		blendfunc blend
		tcMod scale 0.8 0.5
		tcMod scroll -0.1 0.1
		depthWrite
	}
	{
		map textures/outrage/outsky.tga
		blendfunc blend
		tcMod scale 0.8 1
		tcMod scroll -0.2 0.3
		depthWrite
	}
}

If you are using several tcMod's (Texture Coordinate Modification), you have to pay attention of their order. See: http://www.heppler.com/shader/shader/section6.htm#6.6

[RojaN Returned]

Excellent, sst13! Thank you. Loops seamlessly now.

When using multiple tcMod functions during a stage, place the scroll command last in order, because it performs a mod operation to save precision, and that can disturb other operations.

That's from your link.

This should be the LAST tcMod in a stage. Otherwise there may be a popping or snapping visual effect in some shaders.

That's the version from Robotrenegade that I've got bookmarked. Difference in form, not substance. Any reason why one version of the shader manual should be preferred over the other? Or do you need to be cross-referencing different versions?

[Eraser]

I've always preferred the robotrenegade one. Never found fault with it.

[obsidian]

The original shader manual was written by a couple of developers who were at id Software while Quake 3 was under development. It's a good reference, but really old and outdated.

A LOT of work was done both with GtkRadiant and Q3Map2 which added all sorts of new features. Many of these features are extended as shader directives. I used the original shader manual as a reference and built on top of it, documenting the additional features for reference.

[RojaN Returned]

The original shader manual was written by a couple of developers who were at id Software while Quake 3 was under development. It's a good reference, but really old and outdated.

A LOT of work was done both with GtkRadiant and Q3Map2 which added all sorts of new features. Many of these features are extended as shader directives. I used the original shader manual as a reference and built on top of it, documenting the additional features for reference.

Thanks for clearing that up. Among many other things. Quite a few tech questions of mine over the past couple months led, through search, to a thread answered by you.
I had a feeling the robotrenegade one was the authority for those developing now, with q3map2 and modern gtkradiant. Appreciate getting that nailed down.