$seamless scale

From Valve Developer Community
Revision as of 07:19, 17 September 2008 by MrTwoVideoCards (talk | contribs) (Fixed some lines)
Jump to navigation Jump to search

$seamless_scale is a parameter supported by the LightMappedGeneric and WorldVertexTransition shaders. It is to be used in Valve Material Type (VMT) files for the Orange Box version of the Source Engine. It is not supported by any shaders in the Episode 1 version of the Source Engine. This parameter is useful for a material frequently applied to complex displacement surfaces. It removes the unpleasant material-stretching effect.

Basic syntax

$seamless_scale <float> Example:

"LightMappedGeneric"
{
	"$basetexture" "Example\Example01"
	"$surfaceprop" "concrete"
	"$seamless_scale" "0.005"
}

Functionality

Known Problems
A: Materials with this parameter cannot be scaled in the Hammer Face Edit Dialog. They must have the float value changed in their VMT.
B: The 3D window in Hammer may display graphical glitches if a material of this sort is applied to a face.
C: Certain "treatment" mapping techniques either will not function or will create strange lighting artefacts when used with $seamless_scale. These parameters will have to be removed until $seamless_scale is not in use anymore.
Note.png Note: You can negate the functionality a parameter, without removing it outright, by putting two forward slashes (//) before the parameter in the VMT.
Non-functional Treatment Mapping techniques
Normal Mapping
Detail Mapping
Functional Treatment Mapping techniques
Specular Mapping
Specular Mapping utilising Self-Shadowed Bump Maps

Example setup of $seamless_scale with functional Treatment Mapping:

LightMappedGeneric
{
	"$basetexture" "Example\Example01"
	"$surfaceprop" "concrete"
	"$bumpmap" "Example\Example01_height-ssbump"
	"$ssbump" 1
	"$normalmapalphaenvmapmask" 1
	"$envmaptint" "[ .2 .2 .2 ]"
	"$envmap" "cubemaps\cubemap_Example01"
	"$seamless_scale" "0.005"
}

History

According to the Episode 2 commentary, this feature was added in response to difficulties experienced with the creation of the Antlion Caves section. The complicated topography of the areas exaggerated the previously bearable material-stretching effect. This effect is a result of how the Source Engine usually handles displacements, whereby the coordinate system of the material is locked to the vertices of a displacement surface.

When a vertex is translated to a different position, the planes that are naturally created between this vertex and it's neighbouring vertices change size accordingly. Since the material's coordinates are locked to the vertices of each plane, the material must change size, or scale, to fit across the growing/shrinking planes. The material will scale down to fit across a plane that has shrunk, while scaling up to fit across an enlarged plane. If vertices are translated too much, and in too arbitrary a manner, the resulting planes will be wildly different sizes from their surrounding neighbours. Any material applied to such a displacement surface will inevitably then have segments of itself scaled in ridiculously different proportions. One may be twice the X axis scale as it's neighbour, while half the Y axis scale. This will create an aesthetically unpleasing effect, whereby the material appears to stretch at some parts while scrunching up at others.

Without very careful and time consuming attention being paid to the displacement creation, it's hard to avoid this problem in terrain such as caves. Even at that there will still be noticeable stretching. So Valve coded a new feature; $seamless_scale. It separates the material's coordinate system from the vertices of the displacement to which it is applied. Materials can then maintain the same scale across a whole displacement surface, no matter how messy the topography is.