“Revolutions” in texture mapping

April 27th, 2008

The process of texturing/shading a 3D model always begins with UV mapping and for the past 20 years the 3D industry has used traditional UV mapping techniques which relies on cutting up a 3D model and laying the pieces of it onto a 2D grid (the texture):

Tools since the late 90s have become increasingly more sophisticated. We have pelters (as introduced by “Seamless Texture Mapping of Subdivision Surfaces by Model Pelting and Texture Blending” and the Matrix FX developers) and Least Square Conformal Maps. The two big UV layout tools are UVlayout and Unwrap3D which work in conjunction with 3D paint tools like Mudbox, Zbrush, and Deep Paint 3D.

UV mapping is horribly complex and labor intensive. It’s a highly specialized skill that an “artist” needs to learn over a few months.


The main problems are:

1) Seams which are highly noticeable in areas where two parts are joined together (shoulder, hips, neck, etc.)


2) Texture distortion/stretching. This is a subtle problem that is due to improper UV mapping - too few texture pixels (texels) are mapped to a large or uneven area of a 3D model.

This female model almost has no distortion except near the breast area… it is almost perfectly UV mapped as the “texel to pixel ratio” is pretty consistent.

In the last 5 years, computer graphics researchers have been discovering new methods of texturing. The best one I’ve found requires throwing out all previous UV mapping tools and relying on 3D paint programs solely. The algorithm is called PolyCube maps published first in SIGGRAPH 2004.

I discovered it via reading some geometry-based texture papers as physics and new rendering techniques are using textures to represent geometry. Cube maps are traditionally used to represent environments via a 6-sided textured cube:

The idea behind Polycube maps kicks ass… instead of trying to splat arbitrary polygonal geometry into a 2D plane (aka UV mapping) you build a polycube representation of the model that becomes a “cube map hull.” This cube map hull is where the texture lies on - much like in traditional cube mapping. Each vertex in the 3D model contains a UVW co-ordinate that refers to a point on this cube map hull. Unlike cube mapping, this UVW co-ordinate is not the surface normal and is something generated by the Polycube map algorithm.



The entire process is automated after the polycube map and model are fed into the system. Screw pelting and hand moving UVs around in Maya, UVlayout, etc.. The only work required by the artist is creating the polycubes and running some optimizations to reduce texture distortion. The end benefits over UV mapping are:

  1. No seams / seamless. Since we are no longer making surface cuts and the process of UVW layout is automated there are no seams as the entire surface is continuous.
  2. Texture distortion is minimal. Since we are no longer relying on humans to manually layout UVs using projection, pelting, etc. we can algorithmically force uniform texel coverage.
  3. Automatically works on different level of details. Because our UVW parameterization is automated, we can change the 3D model (making it lower or higher resolution) and use the same polycube map (texture and polycube) with minimal visual difference. This feature is called geometric independence and is something available to procedural texturing methods, but not UV-based texturing.

The negative is that all previous 3D renderers have to be changed to NOT use traditional UV mapping and instead use UVW mapping which requires pixel-based sampling operations similar to how current cube mapping works.

Currently, there is no public implementation to generate the polycube map data (only samples), but there is a fragment shader available. Sadly it is for assembly language based OpenGL which is rarely used and not the easiest to understand compared to modern shading languages like Cg and HLSL.

Entry Filed under: Game Development

1 Comment Add your own

  • 1. Casually Hardcore devlog &hellip  |  May 17th, 2008 at 9:33 am

    [...] some back and forth with my modelers about PolyCube maps and how that influences their workflow, I’ve resigned myself to that fact that modelers will [...]

Leave a Comment

You must be logged in to post a comment.

Trackback this post  |  Subscribe to the comments via RSS Feed


Calendar

April 2008
S M T W T F S
« Mar   May »
 12345
6789101112
13141516171819
20212223242526
27282930  

Most Recent Posts