# Mesh Color Textures

## Overview

### The problem

**Texture mapping** is a class of techniques used in virtually all computer graphics applications to describe the high resolution details of a model without increasing the level of detail of the model itself.


However, accurate and fast texture mapping is problematic due to:
1. the issue of **parameterization**, i.e mapping a 3D model coordinate to a (typically) 2D texture coordinate (also referred to as “UV mapping”);
2. **filtering seams** appear in between different patches of a texture as a discontinuity of the color. This happens because the sampling takes values outside the patches, introducing artifacts for artists to clean up.

Solutions to these problems have been proposed which try to hide seams with additional computation in the vertex/fragment shader or try to solve the parametrizatin problem by redefining the texture representation entirely, for example using other data structures such as octrees. These techinuques however have various issues of their own, such as code complexity in the case of shader enhancements or large memory requirements in the case of octrees.

### Previous solutions

To prevent the manual labor of parametrization, previous papers proposed to store color information directly "on" the geometry. Per-face texture mapping (**Ptex**) does it by storing color information on a mesh of quads, while the previous work from the same author (**Mesh Colors**) also uses vertices and edges to store color information and works with triangles as well (See figure 4).


The problem with both solutions is that they introduce run-time costs which limits their use to offline rendering only. The next step is to extend the idea of mesh colors to make it work in a real-time scenario, which is what mesh color textures are for.

### Key idea
<!-- The key idea of the new solution is an extension to previous work on using mesh colors, referred to as mesh color textures. -->

<!-- comment -->

The method uses mesh colors to then generate 2D textures for the GPU to use. This is done because GPU’s are optimized to deal with 2D textures and thus provides greater performance in real time rendering applications.

Mipmaps that are used in the rendering require different treatment than regular 2D texture mapping. This is handled by making a 4D texture coordinate formulation.
To calculate the resulting coordinate for texture lookup the following formula is used $$u_l= u_s/2^l+ u_\delta$$ where $u_l$ is the resulting 2D texture coordinate for mipmap level $l$, $u_s$ is a 2D texture coordinate which changes on each mipmap level and $u_\delta$ is a 2D constant offset per triangle face.

### What they achieve


Mesh colors textures resolve both the parametrization and the filtering problems of texture mapping while introducing only a minimal overhead over standard 2D texture maps (See figure 13).

## Questions

1. What does it mean to store color information "on" the geometry, in practice?
<!-- You store the information about color in the same data structure of the model itself, I guess. -->

2. Where do the 4 dimentions of the 4D texture coordinate system come from?
<!-- A novel 4D texture coordinate formulation that provides correct bilinear filtering for any mipmap level (taken from the article) -->

3. In relation to the equation $u_l= u_s/2^l+ u_\delta$ for calculating the correct 2D texture coordinate, they say that $u_\delta$ must be constant for all vertices of a triangle face. Why is that so?
<!-- u_l for each valid level l must be at the center of a texel (according to the paper). -->

4. In the paper they say that their solution is able to perform mipmapping beyond vertex colors, what could that mean?
<!-- If you stop at vertex color mipmap you can still have different colors for each vertices, sometimes (e.g. very long triangles) this is not the best solution so in the paper they propose a way to generate mipamaps that are not strictly bounded to the geometry. -->

5. One limitation of mesh color textures is that it adds some complexity for texture lookups to the shader. How could this be mitigated?
<!-- Implement a new texture sampling function using our 4D coordinate representation directly -->

###### tags: `chalmers`