UV Rotation & Panning
This section is missing a lot, I've added a small section below since it's a frequently asked question. It would be nice to have some information on how the panner node works, as well as the rotation node.
--Freya Holmér (talk) 18:58, 24 April 2014 (UTC)
Contents
Panner
The panner works by offsetting uv coords so that the texture is moving in a direction, left for example, based on numbers inputted. speed of panner is affected by how large the numbers are. The panner can also be used to simply offset uv coords like the offset controls in the material inspector but with control in the shader itself and not needing a script to move it consistently. To accomplish this, SF has a Panner node or a custom panner can be created manually.
Basic Panner Node
By default, if the 'Dist' input is not attached, the Panner will cause the UV coordinates to constantly pan automatically. The UV coords cannot be changed in the inspector, but only in the SF node tree editor. If a constant value(e.g. value node) is input into the 'Dist' input, the UV coords will be offset once by that amount. A time node can be input to alter the continual panning of the UV coords (see below).
Panner with U and V sliders
Panner node with Time node
Custom(Manually created) Panner w/ properties to control UV speed
Both UV properties can be edited in the Unity inspector.
Rotator
The rotator node works by offsetting uv coords radially(clockwise or counter-clockwise), in radians, to make the texture rotate around a specified point, which is the center(Piv = 0.5, 0.5) by default. If nodes are not connected to both the 'Ang' and 'Spd' inputs, then the rotator will rotate the object at approximately Pi/4 rad/sec counterclockwise. If a constant node (e.g. Value node) is connected to the 'Ang' input, then the rotator will rotate the UV's by that value once. Time nodes upstream of the 'Ang' input will cause continual rotation.
Basic Rotator node with a direction switch
Radially distorting UV's using a rotator
- Note that in the node tree image below, the lower multiply node isn't updating correctly, but the end result is correct*