Simplifying Textured Meshes

 
Important Note

Outdated Version:
You are looking at an outdated documentation version for an older RapidCompact CLI distribution. If you are using a newer version of the CLI please refer to the documentation of the current CLI release version.

< 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 uses 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 is a single related decimation setting where we need to make sure it's switched on:

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

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

    rpdx -s decimation:preserveUVs true -i .\Tutanch_scan.obj -d f:5000 -e result/5K.obj

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 >