Simplifying & Preserving UVs

 
< previous page next page >

Within this tutorial, we are going to use RapidCompact CLI to simplify a textured 3D mesh with UV coordinates. Within the previous tutorial, you have seen how RapidCompact can be used to simplify an untextured mesh, and how the different settings affect the result.

Getting Started: UV-Preserving Decimation, or New UV Atlas & Texture Baking?

Given a high-resolution textured mesh, there are basically two ways to produce a low-poly version that is textured as well.

  1. UV-Preserving Decimation. This is the method covered within this tutorial. Existing texture images from the high-resolution model can still be used.
  2. New UV Atlas & Texture Baking. This is an alternative method to produce a textured low-poly result, where entirely new UVs are created on the low-poly model. The new UV atlas mapping is then used to create new textures from the original ones (texture baking), producing new texture images with a different layout. This way is used by the --compact command, and it is covered within the LOD tutorial.

Using UV-Preserving Decimation

We will now use the first method, UV-preserving decimation, on a simple example mesh of a scanned pharao bust (courtesy of CultLab 3D), which you can download here. There are two related decimation setting where we need to make sure that they are switched on:

Name Type Default Valid Range Quick Description
decimation:preserveUVs Flag false {true, false} preserves texture coordinates during decimation
decimation:preserveMaterialBorders Flag false {true, false} preserves mesh material borders during decimation

Try now to use the UV-preserving decimation on the pharao model:

    rpdx -s decimation:preserveUVs true -s decimation:preserveMaterialBorders true -i .\Tutanch_scan.obj -d f:5000 -e result/5K.obj
    
decimate vs compact The settings can be used in conjunction with either --decimate or --compact. Due to compact being the more smart function the result will continue to decimate instead of stopping at the minimal ammount of polygons and will revert to cutting new UVs and rebaking the textures. The following warning will be thrown in the compact case :
WARNING: Decimation target could not be reached while preserving UVs [...] Reverting to baking materials.
Using decimate, the UV preservation behaves just as in the older RapidCompact Versions and will automatically stop before the mesh breaks - however the decimation target will then be not reached. For more information about this continue reading below.

RapidCompact CLI will generate a simplified version, and the output textures will match exactly with the input ones (in fact, one can use the same images for both versions of the model, which may be one reason to go with UV-preserving simplification).

However, you may realize that the output model does not have 5,000 faces, although we requested that - instead, the model has still more than 100,000 faces left after decimation! RapidCompact also provides us with two warnings:

    WARNING: Could not reach the decimation target. Final face count 112174 (2%).
    WARNING: The original normal maps may look incorrect on the decimated asset.
    

Let's have a look at both of these warnings and see what has happened, and why.

UV Seam Preservation and Mesh Reduction Targets

The first warning from the above example tells us that RapidCompact could not reach the target count of 5,000 faces while preserving UVs. The reason for this is that, with UV-preserving simplification enabled, RapidCompact will not change the shape of the UV boundaries, which requires the simplification algorithm to leave vertices on the UV boundary untouched. That means the more UV seams the original model has, the less freedom the simplifier will have to remove vertices from the model. In the case of our pharao model, there are quite some UV seams (the original is a 3D-scanned and auto-textured model). Looking at the low-poly version, you can see the complex shape of the UV seams, which is exactly preserved in the simplified version, producing a lot of enlongated triangles near the seams (here highlighted in pink):

There is basically no alternative to a result like this, as long as we decide that we want to use the original model's texture on the lowpoly output model as well. As mentioned in the beginning, there is an alternative if we allow ourselves to resample the texture content into new images, which effectively allows RapidCompact to simplify the shape of the boundaries in the texture atlas as well (method covered in the LOD tutorial).

UV Preservation and Normal Maps

In the above example, we also saw a warning about normal maps, stating that original normal maps may look incorrect on the decimated asset. Why do we see this warning, and what does that imply for the result? In a nutshell, the problem is only relevant for tangent-space normal maps, and it only occurs if the tangent spaces of the low-poly model vary significantly from the tangents of the original high-res model. Tangent spaces consist of normal, bitangent and tangent, and the latter two are typically derived from UV coordinates. While the UV-preserving simplification algorithms tries to keep the position and orientation of the UV content as it is, the mesh normals of the low-poly version may differ from the high-poly ones, and hence the tangent spaces may be slightly different. In many cases, the effect on the rendered, normal-mapped model is not notable. However, it may happen that a visible difference occurs. In such cases, one can use RapidCompact to explicitly bake a new normal map, sampling the content from the input normal map and mapping it into the correct tangent spaces of the low-poly version.


< previous page next page >