Simplifying & Preserving UVs

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.

UV-Preserving Decimation. This is the method covered within this tutorial. Existing texture images from the high-resolution model can still be used.
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 -c f:500 -e result.glb

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 try iteratively to reach a valid output amount of triangles. If the initial target is not met, --compact will add 50% of triangles on top of the "mesh breaking point" resulting in a usually slightly higher face count than requested. The following warning will be thrown in the compact case :

WARNING: Could not reach the decimation target. Final face count [...]

Caused by geometry, topology or material preservation constraints.

Decimation target missed. Re-running decimation. [...]

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 might then be not reached either. 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 500 faces, although we requested that - instead, the model has still more than 1,000 faces left after decimation using --decimate or even 150% of that if using --compact! RapidCompact also provides us with a warning:

   WARNING: Could not reach the decimation target. Final face count 1300 (0%).
   Caused by geometry, topology or material preservation constraints.
   Decimation target missed. Re-running decimation. [...]

Let's have a look at 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 500 faces while preserving UVs. The reason for this is that, with UV-preserving simplification enabled, RapidCompact will be constraint by the shape of the UV boundaries, which requires the simplification algorithm to retain the positions of vertices on the UV boundary as good as possible. 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 preserved in the simplified version, producing some enlongated triangles near the seams (here highlighted in pink):

As mentioned in the beginning, there is an alternative if we allow 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

At this point in time, rpdx does not preserve the original input normals. This will be covered in one of the next updates. However, by default, rpdx tries to recalculate normals and re-bake normals maps (using the same UVs) for the optimized low resolution mesh. In some cases this does not work due to overlapping UVs which is indicated by the following warning message:

WARNING: Could not re-bake all normal map textures due to UV overlaps

< previous page next page >