VAT Technical Info
Last updated
Last updated
This page covers the technical aspect of how Sansar VATS are done, This info is aimed towards advanced users who intend to try and create tools or use other programs to create VAT assets. if you wish to use the existing blender tool please see Vats Shader Basics.
Sansar expects both VAT textures (vertex displacement and normal rotation) as float (half) and in a specific format. Each pixel (except the pixel at x=0, y=0, which is the header pixel) specifies the displacement/rotation of a vertex at one point in time. In order to optimize GPU cache, the vertex/frame index is not directly related to a x/y coordinate in the texture but has to be specified in a sequence encoded in a z-curve (see https://en.wikipedia.org/wiki/Z-order_curve).
The order of the sequence is as follows:
First pixel is a header pixel which contains information about the number of vertices and frames.
Then the displacement/rotation of all vertices in the first frame are given.
Then the displacement/rotation of all vertices in the second frame is given and so forth for all frames of the animation.
The header pixel uses the Red and Green channels to encode the total number of vertices. It uses two channels in order to increase the allowed number of vertices beyond the capacity of a half precision number. Sansar will decode the header pixel as follows:
Thus, the header has to be encoded as follows:
The displacement of a vertex at one frame is given by the Red, Green and Blue channel of the corresponding pixel, whereas the color channels directly correspond to the x,y,z displacement, respectively, given in object coordinates.
The rotation of the normal vector (better said the rotation of the tangent space) is specified for each vertex in a separate texture (VAT_normal.exr). Here the Red, Green, Blue and Alpha channel correspond to the x, y, z and w of a rotation quaternion, respectively.
The mesh is given by an fbx format with the following specific requirements:
A secondary uv-map has to be provided to encode the vertex numbering. This is required because the order of vertices may be changed during import into Sansar due to mesh optimization.
Vertices with multiple different normals (e.g. at a sharp edge) need to be split if the animation moves the adjacent faces independently. This is required to specify a unique normal rotation for both sides.
The exported mesh requires a secondary uv-map (which is generated automatically by the Blender add-on). The u/v coordinates of this map specify the vertex index to be used in the displacement and rotation map. Again both channels are used combined to increase the maximum number of vertices to be encoded with half precision. Sansar will decode the vertex index from the u/v coordinates by:
Note that the v coordinate is shifted only by 2047 because Sansar internally flips the v coordinate on import and back in the shader. Therefore, the zero is shifted only by 2047 instead of 2048, which is the maximum number to be encoded by the 10 bit fraction in half precision.
Thus, the uv data has to be encoded as follows:
